[jira] [Commented] (CLOUDSTACK-5205) System vm startup scripts calculate jvm memory wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827404#comment-13827404 ] Prasanna Santhanam commented on CLOUDSTACK-5205: Thanks! Do you think you can submit a patch for this? Please post it on reviewboard.apache.org. Patches left in JIRA tickets generally don't get noticed by the concerned contributors. Here's some guidelines : https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines System vm startup scripts calculate jvm memory wrong Key: CLOUDSTACK-5205 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5205 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Reporter: John E Vincent While attempting to provision beefier system vms, we discovered this bug. The `_run.sh` script in the system vm calculates jvm memory based on 80% of the total memory on the system. This is great up until the point 80% of memory goes above ~1.9G. The system vm templates are all 32-bit and so calculating the size too high will cause the agent jvm to fail to start. The fix is pretty simple with a final sanity check: if [ $maxmem -gt 1900 ] then maxmem=1900 fi -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4878) KVM snapshots are failing at CentOS 6.4
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805121#comment-13805121
]
Prasanna Santhanam commented on CLOUDSTACK-4878:
What's the value of kvm.snapshot.enabled in the global configuration? Is it set
to true?
KVM snapshots are failing at CentOS 6.4
---
Key: CLOUDSTACK-4878
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4878
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0, 4.2.1
Environment: Centos 6.4 x64 recent patches
primary local or NFS and seconday storage on NFS
Reporter: Bjoern Teipel
Priority: Critical
2013-10-15 21:45:59,415 DEBUG [agent.transport.Request]
(AgentManager-Handler-8:null) Seq 1-621806172: Processing: { Ans: , MgmtId:
110493122496, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/4/5/57ef69cd-1bc8-4e47-94c1-84834befaaad,id:0}},result:true,wait:0}}]
}
2013-10-15 21:45:59,415 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-8:null) Seq 1-621806172: No more commands found
2013-10-15 21:45:59,415 DEBUG [agent.transport.Request]
(Job-Executor-2:job-40 = [ 81b303ad-acb2-483f-9571-d09064d1d086 ]) Seq
1-621806172: Received: { Ans: , MgmtId: 110493122496, via: 1, Ver: v1,
Flags: 110, { CopyCmdAnswer } }
2013-10-15 21:45:59,417 DEBUG [storage.snapshot.SnapshotServiceImpl]
(Job-Executor-2:job-40 = [ 81b303ad-acb2-483f-9571-d09064d1d086 ]) Failed to
update snapshot state
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@79fd21d8: SELECT snapshot_store_ref.id,
snapshot_store_ref.store_id, snapshot_store_ref.store_role,
snapshot_store_ref.snapshot_id, snapshot_store_ref.created,
snapshot_store_ref.last_updated, snapshot_store_ref.size,
snapshot_store_ref.physical_size, snapshot_store_ref.parent_snapshot_id,
snapshot_store_ref.job_id, snapshot_store_ref.install_path,
snapshot_store_ref.update_count, snapshot_store_ref.updated,
snapshot_store_ref.state, snapshot_store_ref.ref_cnt,
snapshot_store_ref.volume_id FROM snapshot_store_ref WHERE
snapshot_store_ref.snapshot_id = 1 AND snapshot_store_ref.store_id = 1 AND
snapshot_store_ref.store_role = 'Image' ORDER BY RAND() LIMIT 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:414)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:349)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:859)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.findOneBy(GenericDaoBase.java:870)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.storage.image.db.SnapshotDataStoreDaoImpl.findByStoreSnapshot(SnapshotDataStoreDaoImpl.java:178)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:253)
at
org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:315)
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.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
at
org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
at
org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
at
[jira] [Updated] (CLOUDSTACK-4741) URL of ImageStore not in proper format for XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4741: --- Priority: Critical (was: Major) URL of ImageStore not in proper format for XenServer Key: CLOUDSTACK-4741 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4741 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Snapshot Affects Versions: 4.2.0 Reporter: Gaurav Aradhye Priority: Critical Fix For: 4.3.0 Steps: Hit listImageStores API. check the url attribute of any ImageStore. On KVM and VMWare, the format of url is as below and which is correct: nfs://x.x.x.x:/dir1/dir2/dir3/dir4 While on XenServer, the format of url is as below: nfs://x.x.x.x/dir1/dir2/dir3/dir4 See, the colon (:) is missing after IP address x.x.x.x in XenServer results. Snapshot test cases which test whether the snapshot is present on secondary storage will fail on XenServer due to this formatting issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4161) Typo in Installing Management Server (4.5.3.2. Install on Ubuntu)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794891#comment-13794891 ] Prasanna Santhanam commented on CLOUDSTACK-4161: Applied, thanks commit fc14a52c2237a22d5a3224f3ce943ace6cefc3dd Author: Travis Graham t...@tgraham.us Date: Tue Oct 15 00:00:38 2013 -0400 CLOUDSTACK-4161: fix typo for apt-get command to install cloudstack-management Signed-off-by: Prasanna Santhanam t...@apache.org Typo in Installing Management Server (4.5.3.2. Install on Ubuntu) - Key: CLOUDSTACK-4161 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4161 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Reporter: Charles Galpin Priority: Minor Attachments: management-server-install-client.patch The instructions say to run apt-get install cloudstack-mangagement But the package name is misspelled. It should be apt-get install cloudstack-management -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
Prasanna Santhanam created CLOUDSTACK-4865: -- Summary: KVM deployVM fails on master (f451a811) due to NPE Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4865: --- Affects Version/s: 4.3.0 KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4865: --- Fix Version/s: 4.3.0 KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4865: --- Attachment: 210.tar.bz2 mgmt + agent logs KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Priority: Critical Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4865: --- Priority: Blocker (was: Critical) KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4865: --- Component/s: KVM KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at
[jira] [Resolved] (CLOUDSTACK-4848) Server startup failure on master (Oct 10)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4848. Resolution: Fixed This is fixed now. Server startup failure on master (Oct 10) - Key: CLOUDSTACK-4848 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4848 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Reporter: Prasanna Santhanam Priority: Critical Master is failing server startup since yesterday (oct 9). HEAD is at bb7493775c202f9a0345482b7a9cb478ed48ba11 2013-10-10 13:31:33,808 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40 to410.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:210) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2013-10-10 13:31:33,827 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to upgrade the database com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40to410.sql at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:219) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4791) Server startup failure on master (b44bc9db)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam closed CLOUDSTACK-4791. -- Resolution: Fixed Not observed on master anymore Server startup failure on master (b44bc9db) --- Key: CLOUDSTACK-4791 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4791 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Attachments: logs.tar.bz2 when running from the development environment server starts up perfectly fine but when deployed from packages (rhel) made from master there are several errors and the server startup fails org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataMotionServiceImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: java.util.List org.apache.cloudstack.storage.motion.DataMotionServiceImpl.strategies; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ancientDataMotionStrategy': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.engine.subsystem.api.storage.StorageCacheManager org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.cacheMgr; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageCacheManagerImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithm org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.cacheReplacementAlgorithm; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'StorageCacheReplacementAlgorithm': Invocation of init method failed; nested exception is com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@4e5ced83: SELECT configuration.instance, configuration.component, configuration.name, configuration.value, configuration.default_value, configuration.description, configuration.category, configuration.is_dynamic, configuration.scope, configuration.updated FROM configuration WHERE configuration.name = _binary'storage.cache.replacement.lru.interval' ORDER BY RAND() LIMIT 1 at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at
[jira] [Assigned] (CLOUDSTACK-789) Need test driver to drive the testing of plugins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-789: - Assignee: (was: Prasanna Santhanam) Not looking into this at all. Need test driver to drive the testing of plugins - Key: CLOUDSTACK-789 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-789 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Alex Huang Fix For: Future CloudStack needs test drivers that do the following: Loads a plugin without CloudStack. Loads the tests that test the interface the plugin supports. And run a set of tests to qualify the plugin satisfies how Cloudstack will use the interface. For example, for the networkelement interface, the test driver should be able load any network element and establish the that the interface is set by the network element. This way, any plugin writer have some initial guarantee that their code works the way as expected by CloudStack and they can go into final integration test without causing much problems. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4845) Docs refer to NetScaler SRX instead of SDX
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4845: -- Assignee: Prasanna Santhanam D'oh. Will fix this. Docs refer to NetScaler SRX instead of SDX -- Key: CLOUDSTACK-4845 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4845 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Demetrius Tsitrelis Assignee: Prasanna Santhanam In section 15.17.2.2. Enabling GSLB in NetScaler of the admin guide one finds the text: For NetScaler: IP Address: The IP address of the SRX. I assume this should be SDX instead of SRX? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4845) Docs refer to NetScaler SRX instead of SDX
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4845. Resolution: Fixed Fix Version/s: 4.2.1 This commit is on master commit ee513d2619520828fff8f6b1381b6e6b36614d22 Author: Prasanna Santhanam t...@apache.org Date: Fri Oct 11 11:38:30 2013 +0530 CLOUDSTACK-4845: GSLB: Add NetScaler SDX not an SRX Signed-off-by: Prasanna Santhanam t...@apache.org Docs refer to NetScaler SRX instead of SDX -- Key: CLOUDSTACK-4845 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4845 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Demetrius Tsitrelis Assignee: Prasanna Santhanam Fix For: 4.2.1 In section 15.17.2.2. Enabling GSLB in NetScaler of the admin guide one finds the text: For NetScaler: IP Address: The IP address of the SRX. I assume this should be SDX instead of SRX? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4839) Install Guide, section 3.5, provides wrong list of .deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4839: -- Assignee: Prasanna Santhanam Thanks for the report, I had fixed this for RPMs but clearly missed the DEBs. Thanks Donal for keeping track of StackOverflow! Install Guide, section 3.5, provides wrong list of .deb packages Key: CLOUDSTACK-4839 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4839 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Donal Lafferty Assignee: Prasanna Santhanam See http://stackoverflow.com/questions/19240323/cloudstack-created-7-debian-package-instead-of-16-why -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4839) Install Guide, section 3.5, provides wrong list of .deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792407#comment-13792407 ] Prasanna Santhanam commented on CLOUDSTACK-4839: commit 4642759a19b9a0727a62ca4531b5d7a0dc791b3d Author: Prasanna Santhanam t...@apache.org Date: Fri Oct 11 12:12:04 2013 +0530 CLOUDSTACK-4839: wrong list of packages in debs Also removed the number 7 in the sentence preceding the packages. That puts a dependency on the author correcting the package listing to count the packages and correct this number. Just say, following packages. Signed-off-by: Prasanna Santhanam t...@apache.org Install Guide, section 3.5, provides wrong list of .deb packages Key: CLOUDSTACK-4839 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4839 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Donal Lafferty Assignee: Prasanna Santhanam Fix For: 4.2.0, 4.2.1 See http://stackoverflow.com/questions/19240323/cloudstack-created-7-debian-package-instead-of-16-why -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4839) Install Guide, section 3.5, provides wrong list of .deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4839: --- Fix Version/s: 4.2.1 4.2.0 Install Guide, section 3.5, provides wrong list of .deb packages Key: CLOUDSTACK-4839 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4839 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Donal Lafferty Assignee: Prasanna Santhanam Fix For: 4.2.0, 4.2.1 See http://stackoverflow.com/questions/19240323/cloudstack-created-7-debian-package-instead-of-16-why -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4839) Install Guide, section 3.5, provides wrong list of .deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4839. Resolution: Fixed Install Guide, section 3.5, provides wrong list of .deb packages Key: CLOUDSTACK-4839 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4839 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Donal Lafferty Assignee: Prasanna Santhanam Fix For: 4.2.0, 4.2.1 See http://stackoverflow.com/questions/19240323/cloudstack-created-7-debian-package-instead-of-16-why -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4815) Correct Management Server Install docs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4815. Resolution: Fixed Assignee: Prasanna Santhanam commit 6321f2b5f26134fe4ebd6bfaee351efbb103434f Author: Travis Graham t...@tgraham.us Date: Fri Oct 4 16:46:12 2013 -0400 CLOUDSTACK-4815: adding correct systemvm download links Also adding no_subtree_check to get rid of warning during mount Signed-off-by: Prasanna Santhanam t...@apache.org Correct Management Server Install docs -- Key: CLOUDSTACK-4815 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4815 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Travis Graham Assignee: Prasanna Santhanam Labels: documentation Fix For: 4.2.1 Attachments: management-server-install-flow.patch This adds the correct download URLs for XenServer, KVM, and VMware systemvm images and adds no_subtree_check to the NFS exports settings to silence the warning on mount. It defaults to no_subtree_check, so this just removed the warning on mount. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4815) Correct Management Server Install docs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792411#comment-13792411 ] Prasanna Santhanam commented on CLOUDSTACK-4815: Thanks for the patch. I've applied it to master. Could you file it on reviewboard next time? JIRA patches generally aren't actively tracked by the project. Even an email with [PATCH] in subject would do. Correct Management Server Install docs -- Key: CLOUDSTACK-4815 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4815 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Travis Graham Labels: documentation Fix For: 4.2.1 Attachments: management-server-install-flow.patch This adds the correct download URLs for XenServer, KVM, and VMware systemvm images and adds no_subtree_check to the NFS exports settings to silence the warning on mount. It defaults to no_subtree_check, so this just removed the warning on mount. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4797) Installation guide for 4.2 instructs users to install 4.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4797. Resolution: Fixed Fix Version/s: 4.2.1 4.2.0 Assignee: Prasanna Santhanam commit 312527685039209dfff32d35cd17553e4abdc1d4 Author: Travis Graham t...@tgraham.us Date: Thu Oct 3 18:24:38 2013 -0400 CLOUDSTACK-4797: fixes repo version information for both DEB and RPM repositories Signed-off-by: Prasanna Santhanam t...@apache.org Installation guide for 4.2 instructs users to install 4.1 - Key: CLOUDSTACK-4797 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4797 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Management Server Affects Versions: 4.1.0, 4.2.0 Environment: Debian/Ubuntu Reporter: Douglas Almquist Assignee: Prasanna Santhanam Labels: 4.2, guide, installation Fix For: 4.2.0, Future, 4.2.1 Attachments: configure-package-respository.patch Original Estimate: 1h Remaining Estimate: 1h In the 4.2.0 Installation guide ( It states the following: [cut/paste from web page] 4.4.1. DEB package repository You can add a DEB package repository to your apt sources with the following commands. Please note that only packages for Ubuntu 12.04 LTS (precise) are being built at this time. Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack.list. Add the community provided repository to the file: deb http://cloudstack.apt-get.eu/ubuntu precise 4.1 Note: attempting to change source files to point to the 4.2 branch creates errors. It appears only 4.1 is supported despite the release of 4.2. Reference bug CLOUDSTACK-4804 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4848) Server startup failure on master (Oct 10)
Prasanna Santhanam created CLOUDSTACK-4848: -- Summary: Server startup failure on master (Oct 10) Key: CLOUDSTACK-4848 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4848 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Master is failing server startup since yesterday (oct 9). HEAD is at bb7493775c202f9a0345482b7a9cb478ed48ba11 2013-10-10 13:31:33,808 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40 to410.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:210) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2013-10-10 13:31:33,827 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to upgrade the database com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40to410.sql at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:219) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4848) Server startup failure on master (Oct 10)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4848: --- Component/s: Install and Setup Server startup failure on master (Oct 10) - Key: CLOUDSTACK-4848 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4848 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Reporter: Prasanna Santhanam Priority: Critical Master is failing server startup since yesterday (oct 9). HEAD is at bb7493775c202f9a0345482b7a9cb478ed48ba11 2013-10-10 13:31:33,808 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40 to410.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:210) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2013-10-10 13:31:33,827 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:null) Unable to upgrade the database com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-40to410.sql at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:219) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:275) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:401) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:92) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column name 'size' at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4849) LXC not working when using nonoss build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792360#comment-13792360 ] Prasanna Santhanam commented on CLOUDSTACK-4849: We should get this fixed in the upcoming maintenance release. Do you want to submit a patch for this? LXC not working when using nonoss build --- Key: CLOUDSTACK-4849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4849 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Francois Gaudreault Priority: Critical Fix For: 4.2.1 When you compile nonoss RPMs, the LXC manager will not work. There is a line missing in the nonossComponentContext.xml file. The error in the log will be : Could not find corresponding resource manager for LXC You can fix that by changing the following block: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean To: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=LxcServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4849) LXC not working when using nonoss build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4849: --- Fix Version/s: 4.2.1 LXC not working when using nonoss build --- Key: CLOUDSTACK-4849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4849 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Francois Gaudreault Fix For: 4.2.1 When you compile nonoss RPMs, the LXC manager will not work. There is a line missing in the nonossComponentContext.xml file. The error in the log will be : Could not find corresponding resource manager for LXC You can fix that by changing the following block: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean To: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=LxcServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4791) Server startup failure on master (b44bc9db)
Prasanna Santhanam created CLOUDSTACK-4791: -- Summary: Server startup failure on master (b44bc9db) Key: CLOUDSTACK-4791 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4791 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical when running from the development environment server starts up perfectly fine but when deployed from packages (rhel) made from master there are several errors and the server startup fails org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataMotionServiceImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: java.util.List org.apache.cloudstack.storage.motion.DataMotionServiceImpl.strategies; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ancientDataMotionStrategy': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.engine.subsystem.api.storage.StorageCacheManager org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.cacheMgr; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageCacheManagerImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithm org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.cacheReplacementAlgorithm; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'StorageCacheReplacementAlgorithm': Invocation of init method failed; nested exception is com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@4e5ced83: SELECT configuration.instance, configuration.component, configuration.name, configuration.value, configuration.default_value, configuration.description, configuration.category, configuration.is_dynamic, configuration.scope, configuration.updated FROM configuration WHERE configuration.name = _binary'storage.cache.replacement.lru.interval' ORDER BY RAND() LIMIT 1 at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:397 Logs are attached with db dump from a freshly installed system -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4791) Server startup failure on master (b44bc9db)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4791: --- Attachment: logs.tar.bz2 management server log + dbdump Server startup failure on master (b44bc9db) --- Key: CLOUDSTACK-4791 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4791 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Attachments: logs.tar.bz2 when running from the development environment server starts up perfectly fine but when deployed from packages (rhel) made from master there are several errors and the server startup fails org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataMotionServiceImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: java.util.List org.apache.cloudstack.storage.motion.DataMotionServiceImpl.strategies; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ancientDataMotionStrategy': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.engine.subsystem.api.storage.StorageCacheManager org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.cacheMgr; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageCacheManagerImpl': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithm org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.cacheReplacementAlgorithm; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'StorageCacheReplacementAlgorithm': Invocation of init method failed; nested exception is com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@4e5ced83: SELECT configuration.instance, configuration.component, configuration.name, configuration.value, configuration.default_value, configuration.description, configuration.category, configuration.is_dynamic, configuration.scope, configuration.updated FROM configuration WHERE configuration.name = _binary'storage.cache.replacement.lru.interval' ORDER BY RAND() LIMIT 1 at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at
[jira] [Assigned] (CLOUDSTACK-4590) Export deployment as JSON for marvin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4590: -- Assignee: venkata swamybabu budumuru Export deployment as JSON for marvin Key: CLOUDSTACK-4590 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4590 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam Assignee: venkata swamybabu budumuru Similar to how we deploy a datacenter using deployDataCenter.py, marvin should include the ability to export into JSON format a given deployment. This will require marvin to have admin keys/access -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4677) Switch remoteSSHClient in marvin to use fabric
Prasanna Santhanam created CLOUDSTACK-4677: -- Summary: Switch remoteSSHClient in marvin to use fabric Key: CLOUDSTACK-4677 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4677 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam marvin currently does all ssh connections using remoteSSHClient interface. There are several other methods that basically end up calling remoteSSHClient. Fabric on the other hand provides a more lucid and pythonic interface to deal with ssh-connections. Underneath fabric uses paramiko and provides several improvements 1. KeyPair support 2. Improved logging (current ssh logging is too verbose and hard to troubleshoot with) 3. parallel execution (useful for getting simulataneous LB connections going) In this work we need to deprecate marvin's remoteSSHClient from both the library and the tests and provide fabric interfaces to deal with cloudstack deployedVMs and hosts on the cloud infrasrtucture -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4677) Switch remoteSSHClient in marvin to use fabric
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4677: --- Component/s: marvin Switch remoteSSHClient in marvin to use fabric -- Key: CLOUDSTACK-4677 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4677 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam marvin currently does all ssh connections using remoteSSHClient interface. There are several other methods that basically end up calling remoteSSHClient. Fabric on the other hand provides a more lucid and pythonic interface to deal with ssh-connections. Underneath fabric uses paramiko and provides several improvements 1. KeyPair support 2. Improved logging (current ssh logging is too verbose and hard to troubleshoot with) 3. parallel execution (useful for getting simulataneous LB connections going) In this work we need to deprecate marvin's remoteSSHClient from both the library and the tests and provide fabric interfaces to deal with cloudstack deployedVMs and hosts on the cloud infrasrtucture -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4677) Switch remoteSSHClient in marvin to use fabric
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4677: --- Fix Version/s: Future Switch remoteSSHClient in marvin to use fabric -- Key: CLOUDSTACK-4677 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4677 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam Fix For: Future marvin currently does all ssh connections using remoteSSHClient interface. There are several other methods that basically end up calling remoteSSHClient. Fabric on the other hand provides a more lucid and pythonic interface to deal with ssh-connections. Underneath fabric uses paramiko and provides several improvements 1. KeyPair support 2. Improved logging (current ssh logging is too verbose and hard to troubleshoot with) 3. parallel execution (useful for getting simulataneous LB connections going) In this work we need to deprecate marvin's remoteSSHClient from both the library and the tests and provide fabric interfaces to deal with cloudstack deployedVMs and hosts on the cloud infrasrtucture -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4356) [Automation] TestImplicitPlanner test case failed to deploy VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762733#comment-13762733 ] Prasanna Santhanam commented on CLOUDSTACK-4356: The dedication feature I think looks for free hosts, to it even the systemVMs on the host are going to make it unsuitable. [Automation] TestImplicitPlanner test case failed to deploy VM -- Key: CLOUDSTACK-4356 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4356 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.0 Environment: Automation Reporter: Rayees Namathponnan Fix For: 4.2.0 Test cases integration.component.test_implicit_planner.TestImplicitPlanner.test_01_deploy_vm_with_implicit_planner failed deploy VM Looks like test case trying to deploy VM eventhoug not found any host with empty VM, test case should check for host with empty VM second zone, if still didnt find any host with empty VM, test case should skip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4356) [Automation] TestImplicitPlanner test case failed to deploy VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4356: -- Assignee: Devdeep Singh [~devdeep] can you comment on the implicit/explicit planners please? I thought they looked for free hosts to dedicate which meant hosts that didn't have even the systemVMs or routers on them/? [Automation] TestImplicitPlanner test case failed to deploy VM -- Key: CLOUDSTACK-4356 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4356 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.0 Environment: Automation Reporter: Rayees Namathponnan Assignee: Devdeep Singh Fix For: 4.2.0 Test cases integration.component.test_implicit_planner.TestImplicitPlanner.test_01_deploy_vm_with_implicit_planner failed deploy VM Looks like test case trying to deploy VM eventhoug not found any host with empty VM, test case should check for host with empty VM second zone, if still didnt find any host with empty VM, test case should skip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4630) Cannot apply userdata unless all NICs support userdata
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4630: --- Labels: integration-test (was: ) Cannot apply userdata unless all NICs support userdata -- Key: CLOUDSTACK-4630 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4630 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.1 Environment: CentOS 6.4 x86_64 Reporter: Dave Garbus Labels: integration-test To reproduce this issue, follow the steps below: 1. Create two network offerings, one with UserData service (virtual router) and one without. 2. Add two NICs to the virtual machine with networks corresponding to each network offering above. 3. Call updateVirtualMachine on the VM, specifying userdata. The update will fail with the following error: : Service UserData is not supported in the network id=217 If the NIC without UserData support is removed, the update will go through without issue. In my opinion, this should not cause the whole update to fail, but only update UserData for the relevant NICs. Full trace below: 2013-09-09 14:40:21,316 ERROR [cloud.api.ApiServer] (http-6443-exec-3:null) unhandled exception executing api command: updateVirtualMachine com.cloud.exception.UnsupportedServiceException: Service UserData is not supported in the network id=217 at com.cloud.network.dao.NetworkServiceMapDaoImpl.getProviderForServiceInNetwork(NetworkServiceMapDaoImpl.java:126) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkModelImpl.getUserDataUpdateProvider(NetworkModelImpl.java:824) at com.cloud.vm.UserVmManagerImpl.updateUserDataInternal(UserVmManagerImpl.java:2561) at com.cloud.vm.UserVmManagerImpl.updateVirtualMachine(UserVmManagerImpl.java:2532) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.UpdateVMCmd.execute(UpdateVMCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:505) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:355) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:302) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4608) [Automation] SSVM test cases failing with error 'TestSSVMs' object has no attribute 'config'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758819#comment-13758819 ] Prasanna Santhanam commented on CLOUDSTACK-4608: That commit fixes the dependency where we assume credentials to by root/password. We should not do that. All the fixes such as this will break your tests, but they should get the credentials from the config file. So, can you please investigate this further? [Automation] SSVM test cases failing with error 'TestSSVMs' object has no attribute 'config' Key: CLOUDSTACK-4608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4608 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.1 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.2.1 SSVM test cases failing after below check-in https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=2575ded3f32e7c27315c5701bbc4fdbc44615080 Test cases failing with below error Error Message 'TestSSVMs' object has no attribute 'config' begin captured logging testclient.testcase.TestSSVMs: DEBUG: Running SSVM check script - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/smoke/test_ssvm.py, line 345, in test_03_ssvm_internals host.user, host.passwd = get_host_credentials(self.config, host.ipaddress) 'TestSSVMs' object has no attribute 'config' begin captured logging testclient.testcase.TestSSVMs: DEBUG: Running SSVM check script - end captured logging - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4617) Xenserver 6.1 - Add host succeeds but gets into Alert state due to Unable to create local link network. It remains in Alert state for a while and then gets to
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4617. Resolution: Duplicate CLOUDSTACK-4499 and CLOUDSTACK-3839 Xenserver 6.1 - Add host succeeds but gets into Alert state due to Unable to create local link network. It remains in Alert state for a while and then gets to UP state. -- Key: CLOUDSTACK-4617 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4617 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: Build from 4.2-forward Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.2.1 Attachments: hostdown.rar Xenserver 6.1 - Add host succeeds but gets into Alert state. It remains in Alert state for a while and then gets to UP state. Steps to reproduce the problem: In my case I already had 1 zone. Create another advanced zone with 1 Xenserver host. As part of zone creation wizard , provide all the values for zone creation including primary and secondary storage details. Primary storage creation fails with error - Failed to delete storage pool on host Following exception seen in management server logs: 2013-09-05 11:51:25,894 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) ===START=== 10.215.3.9 -- GET comman d=createStoragePoolzoneid=b34c3dc3-27c3-4f9a-9173-c74b04a4acabpodId=fde823c6-f763-480e-a5bf-c96f4e6e43faclusteri d=3658d76d-fa9a-41c1-95a9-0c1688c2707cname=ps1scope=clusterurl=nfs%3A%2F%2F10.223.110.232%2Fexport%2Fhome%2Fsang eetha%2F307%2Fzone2-primaryresponse=jsonsessionkey=e4LjGKV4k%2FmbX%2BczFre8RM8zhXI%3D_=1378408027682 2013-09-05 11:51:25,975 DEBUG [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl] (catalina-exec-20:null) createPool Params @ scheme - nfs storageHost - 10.223.110.232 hostPath - /export/home/sangeetha/307/zone2-primary port - -1 2013-09-05 11:51:26,125 DEBUG [cloud.storage.StorageManagerImpl] (catalina-exec-20:null) Failed to add data store com.cloud.utils.exception.CloudRuntimeException: No host up to associate a storage pool with in cluster 2 at org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.attachCluster(CloudStackPrimaryDataStoreLifeCycleImpl.java:371) at com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:749) at com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:177) at org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:168) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-05
[jira] [Commented] (CLOUDSTACK-4603) Ability to configure a syslog destination for a virtual router / systemvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757758#comment-13757758 ] Prasanna Santhanam commented on CLOUDSTACK-4603: +1 - I was hoping to add a ticket for this myself. I would really love to see this. Centralised logging of all cloudstack managed services would be great to pump them into better log gathering/analysis tools down the pipeline. The Management server log, log for KVM agents is easily redirected to a syslog server but not so the case with router VM logs that go to /var/log/messages , dns/ dhcp logs etc. Ability to configure a syslog destination for a virtual router / systemvm - Key: CLOUDSTACK-4603 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4603 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM, Virtual Router Reporter: Roeland Kuipers In order to improve monitoring and insights in a system / routervm. We like to see an option to send logging from system / routing vm's to a syslog server. Destination preferably configurable per network and globally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4608) [Automation] SSVM test cases failing with error 'TestSSVMs' object has no attribute 'config'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4608: -- Assignee: Rayees Namathponnan This is the same problem as CLOUDSTACK-4511. The test has no problems in my setup. What is your kvm config? Can you debug this test further [Automation] SSVM test cases failing with error 'TestSSVMs' object has no attribute 'config' Key: CLOUDSTACK-4608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4608 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.1 Reporter: Rayees Namathponnan Assignee: Rayees Namathponnan Priority: Blocker Fix For: 4.2.1 SSVM test cases failing after below check-in https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=2575ded3f32e7c27315c5701bbc4fdbc44615080 Test cases failing with below error Error Message 'TestSSVMs' object has no attribute 'config' begin captured logging testclient.testcase.TestSSVMs: DEBUG: Running SSVM check script - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/smoke/test_ssvm.py, line 345, in test_03_ssvm_internals host.user, host.passwd = get_host_credentials(self.config, host.ipaddress) 'TestSSVMs' object has no attribute 'config' begin captured logging testclient.testcase.TestSSVMs: DEBUG: Running SSVM check script - end captured logging - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4599) GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756643#comment-13756643 ] Prasanna Santhanam commented on CLOUDSTACK-4599: There are a couple more things of interest that will be required to assess what's going on here. For starters we'll need the SMlog (/var/log/SMlog) from the XenServer host where the network configuration was attempted and failed. GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1 Key: CLOUDSTACK-4599 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4599 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Network Devices, XenServer Affects Versions: 4.1.1 Environment: Management server: CentOS 6.4 x86_64, CentOS Plus repo enabled, also pri/sec storage NFS server Hosts: XenServer 6.1, included OVS (1.4.2?) All the above running on ESX 5.1 (but I don't think it's a factor), with recommended CPU and RAM configurations. Reporter: David Black Each hypervisor has two NICs, one on a public/management network, the other dedicated to private/isolated traffic. Both NICs (as xenbrX) have IP addresses and each host can reach the other over the respective bridge IP addresses. The bridge networks are labeled Public (xenbr0) and Private (xenbr1). The xenbr1 bridge IP subnet has no default gateway as it's there only for the tunnel endpoints on each host. Guest networking is configured to be on the Private label, isolation type GRE. In addition, in Global Settings, sdn.ovs.controller = true and sdn.ovs.controller.default.label = Private. I tried VLAN (vNet) ranges of 1-4094 and 0-2147483647. In the below example it was set to the latter and picked 10960. BTW, it took quite a bit of scouring the net to find out how to config and what hypervisor (XenServer only) GRE tunnels should work with, in 4.1.1. Also, I'd prefer to use KVM but understand that support is also in the process of being implemented. I had initially tried using XCP 1.6 and received a different error, then realized XCP support isn't yet finished. I thought XenServer 6.1 should work though. The xapiX bridges are set up on the host and a vifX.Y appears to be added for the tunnel endpoints, then the next step - I guess creating the tunnel itself, fails. In this example, both the virtual router and single isolated VM were on the same host... but I also could not migrate either one, receiving a VM requires network error. I won't provide details of that second error right now, but can if desired. Below is an excerpt of the management log Please let me know what other details to provide. If desired, I can arrange access to the vCloud Director system on which it's running, preferably via IPv6 and/or of course collect more logs, run tests, etc. 2013-09-02 22:11:38,508 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-407:null) Xen Server network for tunnels found:OVSTunnel10960 2013-09-02 22:11:38,579 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-407:null) Create a vif on dom0 for tunnel network for account 10960 2013-09-02 22:11:38,873 WARN [xen.resource.CitrixResourceBase] (DirectAgent-407:null) createandConfigureTunnelNetwork failed The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.xensource.xenapi.Types.checkResponse(Types.java:1694) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VIF.plug(VIF.java:846) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:655) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.configureTunnelNetwork(CitrixResourceBase.java:745) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5135) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:541) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at
[jira] [Created] (CLOUDSTACK-4589) Remove marvin dependency from api-doc
Prasanna Santhanam created CLOUDSTACK-4589: -- Summary: Remove marvin dependency from api-doc Key: CLOUDSTACK-4589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4589 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam ApiDiscovery exposes in json the CloudStack API DSL. However, marvin build depends on API doc generated as XML. Remove this dependency and instead output commands.xml and commands.json from the apidoc build which can be used as precache from within marvin's packaging. So that at install-time marvin can build its libraries or choose to sync (like cloudmonkey) against a CloudStack deployment This precached json will also allow one to build marvin and various other language bindings for CloudStack with ease. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4589) Remove marvin dependency from api-doc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4589: --- Component/s: Test Tools Remove marvin dependency from api-doc - Key: CLOUDSTACK-4589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4589 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Test Tools Reporter: Prasanna Santhanam ApiDiscovery exposes in json the CloudStack API DSL. However, marvin build depends on API doc generated as XML. Remove this dependency and instead output commands.xml and commands.json from the apidoc build which can be used as precache from within marvin's packaging. So that at install-time marvin can build its libraries or choose to sync (like cloudmonkey) against a CloudStack deployment This precached json will also allow one to build marvin and various other language bindings for CloudStack with ease. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-981) marvin integration lib: use factories to define default test data
[ https://issues.apache.org/jira/browse/CLOUDSTACK-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-981: -- Component/s: (was: Test Tools) marvin marvin integration lib: use factories to define default test data - Key: CLOUDSTACK-981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-981 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.0.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Fix For: Future Currently we use bare python dictionaries to define the test data and its defaults within an integration test. This should be improved to use factories using a library like https://github.com/dnerdy/factory_boy. Not only will this enable for easier auto-completion when writing the test. It also allows us to see the test data in a simple hierarchical format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1038) Marvin integration lib: Support for multiple apiclient handlers for multiple region deployments.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasanna Santhanam updated CLOUDSTACK-1038:
---
Issue Type: Improvement (was: Task)
Marvin integration lib: Support for multiple apiclient handlers for multiple
region deployments.
Key: CLOUDSTACK-1038
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1038
Project: CloudStack
Issue Type: Improvement
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Test Tools
Affects Versions: 4.1.0
Reporter: Sangeetha Hariharan
Assignee: Prasanna Santhanam
Marvin integration lib: Support for multiple apiclient handlers for multiple
region deployments.
With the new feature - Regions, we will be allowed to have multiple
management servers each servicing 1 region, be part of the same cloud
deployment.
We need to enhance our libraries to support the concept of having multiple
management servers as part of 1 deployment so with in our Test Cases we can
get multiple apiclient (and db) handlers for each of the management servers.
In the following configuration file , we could have multiple pairs of dbSvr
and mgtSvr entries:
{
dbSvr: {
dbSvr: 10.223.195.105,
passwd: ,
db: cloud,
port: 3306,
user: cloud
},
logger: [
{
name: TestClient,
file: testclient.log
},
{
name: TestCase,
file: testcase.log
}
],
mgtSvr: [
{
mgtSvrIp: 10.223.195.105,
port: 8096
}
]
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4589) Remove marvin dependency from api-doc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4589: --- Component/s: (was: Test Tools) marvin Remove marvin dependency from api-doc - Key: CLOUDSTACK-4589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4589 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam ApiDiscovery exposes in json the CloudStack API DSL. However, marvin build depends on API doc generated as XML. Remove this dependency and instead output commands.xml and commands.json from the apidoc build which can be used as precache from within marvin's packaging. So that at install-time marvin can build its libraries or choose to sync (like cloudmonkey) against a CloudStack deployment This precached json will also allow one to build marvin and various other language bindings for CloudStack with ease. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-989) marvin: jsonHelper deserialization results in unfilled attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasanna Santhanam updated CLOUDSTACK-989:
--
Component/s: (was: Test Tools)
marvin
marvin: jsonHelper deserialization results in unfilled attributes
-
Key: CLOUDSTACK-989
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-989
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.0.0
Reporter: Prasanna Santhanam
Assignee: Prasanna Santhanam
Fix For: Future
marvin:jsonHelper.py deserializes the entire object into entity.entity field
when 'entity' is present as an attribute in the response and failing to fill
in other attributes in the response class of entity.
For instance when the associateIpAddress is called to acquire ip address in a
zone. the response has the following:
result = '{ queryasyncjobresultresponse: { accountid: 2, userid:
2, cmd: com.cloud.api.commands.AssociateIPAddrCmd, jobstatus: 1,
jobprocstatus: 0, jobresultcode: 0, jobresulttype: object,
jobresult: { ipaddress: { id: 25065307-673a-4047-9a85-10b520674fb7,
ipaddress: 10.223.137.67, allocated: 2013-01-02T13:39:33-0800,
zoneid: b2aeb0e8-7c32-4564-80d6-631e745dd745, zonename: zone1,
issourcenat: false, account: test-KE15DK, domainid: 1, domain:
ROOT, forvirtualnetwork: true, vlanid:
953c4b02-bbde-48e1-98c5-20c0888016d5, vlanname: 1371, isstaticnat:
false, issystem: false, associatednetworkid:
1968a6e1-42c3-4d5d-ace4-f692e8d62ba8, associatednetworkname:
test-KE15DK-network, networkid: 8366fd1e-5c79-42b8-81fb-031ddafa589d,
state: Allocating, physicalnetworkid:
cea412ae-d62c-45d6-903b-81e8b2b926a0, tags: [] } }, created:
2013-01-02T13:39:33-0800, jobid: 14f3f4e8-edbe-424f-93f8-5118f4f90939 }
}'
result = getResultObj(result,
associateIpAddress.associateIpAddressResponse())
ipaddr = result.jobresult
print ipaddr.id
print ipaddr.ipaddress.id
print ipaddr.ipaddress.zonename
print ipaddr.ipaddress.ipaddress
print ipaddr.ipaddress.zoneid
None
25065307-673a-4047-9a85-10b520674fb7
zone1
10.223.137.67
b2aeb0e8-7c32-4564-80d6-631e745dd745
The response object is as follows:
class associateIpAddressResponse (baseResponse):
def __init__(self):
public IP address id
self.id = None
the account the public IP address is associated with
self.account = None
date the public IP address was acquired
self.allocated = None
the ID of the Network associated with the IP address
self.associatednetworkid = None
the name of the Network associated with the IP address
self.associatednetworkname = None
the domain the public IP address is associated with
self.domain = None
the domain ID the public IP address is associated with
self.domainid = None
the virtual network for the IP address
self.forvirtualnetwork = None
public IP address
self.ipaddress = None
true if the IP address is a source nat address, false otherwise
self.issourcenat = None
true if this ip is for static nat, false otherwise
self.isstaticnat = None
true if this ip is system ip (was allocated as a part of deployVm
or createLbRule)
self.issystem = None
the ID of the Network where ip belongs to
self.networkid = None
the physical network this belongs to
self.physicalnetworkid = None
the project name of the address
self.project = None
snip
Because the response contains an attribute by the name 'ipaddress' we fill in
the result of the deserialization into that attribute and fail to fill in the
rest of the response object.
This results in confusion when inspecting the response:
In some places we have:
account.account.name and in others we have virtualmachine.id
It is logical and intuitive to not have to make a second indirection from the
resulting object that came back as response. The corresponding tests will
also need to be corrected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1038) Marvin integration lib: Support for multiple apiclient handlers for multiple region deployments.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasanna Santhanam updated CLOUDSTACK-1038:
---
Component/s: (was: Test Tools)
marvin
Marvin integration lib: Support for multiple apiclient handlers for multiple
region deployments.
Key: CLOUDSTACK-1038
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1038
Project: CloudStack
Issue Type: Improvement
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.1.0
Reporter: Sangeetha Hariharan
Assignee: Prasanna Santhanam
Marvin integration lib: Support for multiple apiclient handlers for multiple
region deployments.
With the new feature - Regions, we will be allowed to have multiple
management servers each servicing 1 region, be part of the same cloud
deployment.
We need to enhance our libraries to support the concept of having multiple
management servers as part of 1 deployment so with in our Test Cases we can
get multiple apiclient (and db) handlers for each of the management servers.
In the following configuration file , we could have multiple pairs of dbSvr
and mgtSvr entries:
{
dbSvr: {
dbSvr: 10.223.195.105,
passwd: ,
db: cloud,
port: 3306,
user: cloud
},
logger: [
{
name: TestClient,
file: testclient.log
},
{
name: TestCase,
file: testcase.log
}
],
mgtSvr: [
{
mgtSvrIp: 10.223.195.105,
port: 8096
}
]
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4589) Remove marvin dependency from api-doc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4589: --- Affects Version/s: 4.0.2 Remove marvin dependency from api-doc - Key: CLOUDSTACK-4589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4589 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.0.2 Reporter: Prasanna Santhanam ApiDiscovery exposes in json the CloudStack API DSL. However, marvin build depends on API doc generated as XML. Remove this dependency and instead output commands.xml and commands.json from the apidoc build which can be used as precache from within marvin's packaging. So that at install-time marvin can build its libraries or choose to sync (like cloudmonkey) against a CloudStack deployment This precached json will also allow one to build marvin and various other language bindings for CloudStack with ease. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4590) Export deployment as JSON for marvin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4590: --- Component/s: marvin Export deployment as JSON for marvin Key: CLOUDSTACK-4590 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4590 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam Similar to how we deploy a datacenter using deployDataCenter.py, marvin should include the ability to export into JSON format a given deployment. This will require marvin to have admin keys/access -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4590) Export deployment as JSON for marvin
Prasanna Santhanam created CLOUDSTACK-4590: -- Summary: Export deployment as JSON for marvin Key: CLOUDSTACK-4590 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4590 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Similar to how we deploy a datacenter using deployDataCenter.py, marvin should include the ability to export into JSON format a given deployment. This will require marvin to have admin keys/access -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2721) Marvin cloudstackConnection fails if no port is specified
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-2721: --- Component/s: (was: Test Tools) marvin Marvin cloudstackConnection fails if no port is specified - Key: CLOUDSTACK-2721 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2721 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.1.0, 4.2.0 Environment: python 2.7 Reporter: sebastien goasguen If a CloudStack enpoint without a port defined is specified, then Marvin will fail. You can bypass this by using the IP address of the endpoint and the port but if you want to use a DNS record of an endpoint it won't work. cloudstackConnection.py could be updated a bit so that if no port is passed (integration port is not assumed) and the urlopen query does not try to put a port in there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1906) marvin and cloudmonkey API requesters to be the same
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-1906: --- Fix Version/s: (was: 4.2.0) Future marvin and cloudmonkey API requesters to be the same Key: CLOUDSTACK-1906 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1906 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey, marvin Reporter: Prasanna Santhanam Fix For: Future Both marvin and cloudmonkey should use the same request/response code to communicate with the management server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1952) Provide a DSL framework for cloudstack Marvin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-1952: --- Component/s: (was: Test Tools) marvin Provide a DSL framework for cloudstack Marvin - Key: CLOUDSTACK-1952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1952 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam Fix For: Future DSLs are very effective to improve behaviour drive development. It also eases test case writing and doesn't assume any prior programming knowledge. Today marvin is capable of doing unit-test style development but at the cost of assuming python knowledge. We need to simplify this. A pythonic framework like Konira or Intellect will be required to implement this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1906) marvin and cloudmonkey API requesters to be the same
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-1906: --- Component/s: (was: Test Tools) marvin Cloudmonkey marvin and cloudmonkey API requesters to be the same Key: CLOUDSTACK-1906 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1906 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey, marvin Reporter: Prasanna Santhanam Fix For: 4.2.0 Both marvin and cloudmonkey should use the same request/response code to communicate with the management server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1075) create an utility in Marvin to support nsnitro
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-1075: --- Component/s: (was: Test Tools) marvin create an utility in Marvin to support nsnitro --- Key: CLOUDSTACK-1075 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1075 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.1.0, 4.2.0 Reporter: venkata swamybabu budumuru Assignee: venkata swamybabu budumuru Fix For: Future There is a library available in python for managing NetScaler using Nitro API. Here is the link : http://pypi.python.org/pypi/nsnitro It will be good to integrate this in to Marvin framework for verification tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1075) create an utility in Marvin to support nsnitro
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-1075: --- Fix Version/s: (was: 4.2.0) Future create an utility in Marvin to support nsnitro --- Key: CLOUDSTACK-1075 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1075 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Test Tools Affects Versions: 4.1.0, 4.2.0 Reporter: venkata swamybabu budumuru Assignee: venkata swamybabu budumuru Fix For: Future There is a library available in python for managing NetScaler using Nitro API. Here is the link : http://pypi.python.org/pypi/nsnitro It will be good to integrate this in to Marvin framework for verification tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4591) Move marvin to unittest2 to remove dependency on Python 2.7
Prasanna Santhanam created CLOUDSTACK-4591: -- Summary: Move marvin to unittest2 to remove dependency on Python 2.7 Key: CLOUDSTACK-4591 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4591 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Unittest2 (https://pypi.python.org/pypi/unittest2) is a backport of features in Python 2.7 to older pythons. Because of marvin using class level setup/teardown it was tied with Python 2.7 but with unittest2 this dependency should be removed easily -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4591) Move marvin to unittest2 to remove dependency on Python 2.7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4591: --- Component/s: marvin Move marvin to unittest2 to remove dependency on Python 2.7 --- Key: CLOUDSTACK-4591 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4591 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Prasanna Santhanam Fix For: Future Unittest2 (https://pypi.python.org/pypi/unittest2) is a backport of features in Python 2.7 to older pythons. Because of marvin using class level setup/teardown it was tied with Python 2.7 but with unittest2 this dependency should be removed easily -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4591) Move marvin to unittest2 to remove dependency on Python 2.7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4591: --- Fix Version/s: Future Move marvin to unittest2 to remove dependency on Python 2.7 --- Key: CLOUDSTACK-4591 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4591 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Fix For: Future Unittest2 (https://pypi.python.org/pypi/unittest2) is a backport of features in Python 2.7 to older pythons. Because of marvin using class level setup/teardown it was tied with Python 2.7 but with unittest2 this dependency should be removed easily -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
Prasanna Santhanam created CLOUDSTACK-4567: -- Summary: [DOC] Correct incubator links in the getting-release and gpg verification sections Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4567. Resolution: Fixed Needs cherry-picking to 4.2 [DOC] Correct incubator links in the getting-release and gpg verification sections -- Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Install and Setup Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Fix For: 4.2.0 Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4567: --- Fix Version/s: 4.2.0 [DOC] Correct incubator links in the getting-release and gpg verification sections -- Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Install and Setup Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Fix For: 4.2.0 Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4567: --- Affects Version/s: 4.2.0 [DOC] Correct incubator links in the getting-release and gpg verification sections -- Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Install and Setup Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4567: --- Component/s: Install and Setup Doc [DOC] Correct incubator links in the getting-release and gpg verification sections -- Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Install and Setup Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4567) [DOC] Correct incubator links in the getting-release and gpg verification sections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4567: -- Assignee: Prasanna Santhanam [DOC] Correct incubator links in the getting-release and gpg verification sections -- Key: CLOUDSTACK-4567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4567 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Section 3.1 3.1. Getting the release You can download the latest CloudStack release from the Apache CloudStack project download page1. The link still points to the download page on the incubator. Section on verifying the GPG keys has wrong link to the KEYS file on incubator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4573) Aquire IP address above domain limit in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4573: --- Labels: integration-test (was: ) Aquire IP address above domain limit in VPC --- Key: CLOUDSTACK-4573 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4573 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.1 Reporter: Daan Hoogland Labels: integration-test It is possible to aquire more public IP addresses than allowed according to the domain limit, the steps are as followed: user has a limit of 2 ips domain has a limit of 5 ips 1) create a VPC, this will aquire a public IP address for source nat 2) create a network (not in the VPC) and aquire an IP address, we are now at the max of two allowed public IP address 3) create one or more networks on the VPC 4) under IP addresses (VPC configuration) aquire IP address We now have 3 IP addresses aquired, I tested more, I was allowed up to 7, at which time there was no more free IP addresses available in cloudstack. conclusion: the non VPC network is correctly adhering to the domain limit, but the VPC is not, and IP addresses on the VPC are not counted for when checking the domain limit. Strange thing is though, that cloudstack is checking the IP limit during the creation of a VPC, you cannot create a VPC when you have already reached your IP limit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Description: See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to support the same VLAN on multiple physical networks the migration of VMs from hosts prior the upgrade to the ones added after the upgrade will fail. In order to fix this rename the bridges is required to allow migration to work. This can be done by running the cloudstack-agent-upgrade script. The original bug is still undergoing testing, but these are the initial instructions was: See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work -- Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, KVM, Upgrade Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Jessica Tomechak Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to support the same VLAN on multiple physical networks the migration of VMs from hosts prior the upgrade to the ones added after the upgrade will fail. In order to fix this rename the bridges is required to allow migration to work. This can be done by running the cloudstack-agent-upgrade script. The original bug is still undergoing testing, but these are the initial instructions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4575: --- Labels: integration-test (was: ) [Portable IP] disassociating a transferred public IP is failing with exception -- Key: CLOUDSTACK-4575 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Chiradeep Vittal Assignee: Murali Reddy Labels: integration-test Steps to reproduce: 1. Have latest CloudStack with at least 2 advanced zone. 2. Go to Regions - local - portable IP - add an ip range like below Gateway : 10.147.33.1 startIp : 10.147.33.3 endip : 10.147.33.10 vlan : 33 subnet : 255.255.255.128 3. login as a non-ROOT admin username : dom1User1 password : password domain : dom1 4. create the following isolated networks in each zone - Network1Zone1 - Network1Zone2 5. deploy the following VMs in each network - vm1Zone1 connected to Network1Zone1 - vm1Zone2 connected to Network1Zone2 6. Acquire and associate a portable IP to Network1Zone1 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of Network1Zone2 and add firewall rule for ssh port Observations: (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and able ssh to the portable IP without any issuees. 8. disassociate above portable IP from Network1Zone2. Observations: (ii) sequence of things happened as mentioned below - disassociate happened without any issues which cleaned the eth interface from router etc.., but, - it again initiated IPASSOC on its own for the same portable IP which resulted in the following error and thus this IP stuck in release state forever. (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4581) dissociate transferred public ip should succeed
Prasanna Santhanam created CLOUDSTACK-4581: -- Summary: dissociate transferred public ip should succeed Key: CLOUDSTACK-4581 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4581 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Steps for this automated test are in CLOUDSTACK-4575. Needs coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4581) dissociate transferred public ip should succeed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4581: --- Affects Version/s: 4.2.0 dissociate transferred public ip should succeed --- Key: CLOUDSTACK-4581 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4581 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical Steps for this automated test are in CLOUDSTACK-4575. Needs coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Component/s: Upgrade [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work -- Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Affects Version/s: 4.2.0 [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work -- Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
Prasanna Santhanam created CLOUDSTACK-4550: -- Summary: [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Component/s: KVM [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work -- Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Upgrade Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Component/s: Doc [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work -- Key: CLOUDSTACK-4550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, KVM, Upgrade Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as part of upgrade in release notes once the fix for the bug is verified to work After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4405) (Upgrade) Migrate failed between existing hosts and new hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753310#comment-13753310 ] Prasanna Santhanam commented on CLOUDSTACK-4405: Note to include the cloudstack-agent-upgrade in release docs. Added doc bug CLOUDSTACK-4450 which needs information after verification of this bug. (Upgrade) Migrate failed between existing hosts and new hosts - Key: CLOUDSTACK-4405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4405 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0, 4.2.0 Environment: CS 4.1 Reporter: Wei Zhou Assignee: edison su Priority: Blocker Fix For: 4.1.1, 4.2.0, 4.2.1 There are two hosts (cs-kvm001, cs-kvm002) in old 2.2.14 environment . After upgrade from 2.2.14 to 4.1, I added two new hosts (cs-kvm003, cs-kvm004). The migration between cs-kvm001 and cs-kvm002, or cs-kvm003 and cs-kvm004 succeed. However, the migration from cs-kvm001/002 to the new hosts (cs-kvm003, cs-kvm004) failed. 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) nic=[Nic:Guest-10.11.110.231-vlan://110] 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) creating a vlan dev and bridge for guest traffic per traffic label cloudbr0 2013-08-19 16:57:31,051 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: /bin/bash -c brctl show | grep cloudVirBr110 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Exit value is 1 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) 2013-08-19 16:57:31,063 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/vnet/modifyvlan.sh -v 110 -p em1 -b brem1-110 -o add 2013-08-19 16:57:31,121 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Execution is successful. 2013-08-19 16:57:31,122 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config This is because the bridge name on old hosts are cloudVirBr110, and brem1-110 on new hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-4405) (Upgrade) Migrate failed between existing hosts and new hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753310#comment-13753310 ] Prasanna Santhanam edited comment on CLOUDSTACK-4405 at 8/29/13 5:17 AM: - Note to include the cloudstack-agent-upgrade in release docs. Added doc bug CLOUDSTACK-4550 which needs information after verification of this bug. was (Author: tsp): Note to include the cloudstack-agent-upgrade in release docs. Added doc bug CLOUDSTACK-4450 which needs information after verification of this bug. (Upgrade) Migrate failed between existing hosts and new hosts - Key: CLOUDSTACK-4405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4405 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0, 4.2.0 Environment: CS 4.1 Reporter: Wei Zhou Assignee: edison su Priority: Blocker Fix For: 4.1.1, 4.2.0, 4.2.1 There are two hosts (cs-kvm001, cs-kvm002) in old 2.2.14 environment . After upgrade from 2.2.14 to 4.1, I added two new hosts (cs-kvm003, cs-kvm004). The migration between cs-kvm001 and cs-kvm002, or cs-kvm003 and cs-kvm004 succeed. However, the migration from cs-kvm001/002 to the new hosts (cs-kvm003, cs-kvm004) failed. 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) nic=[Nic:Guest-10.11.110.231-vlan://110] 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) creating a vlan dev and bridge for guest traffic per traffic label cloudbr0 2013-08-19 16:57:31,051 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: /bin/bash -c brctl show | grep cloudVirBr110 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Exit value is 1 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) 2013-08-19 16:57:31,063 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/vnet/modifyvlan.sh -v 110 -p em1 -b brem1-110 -o add 2013-08-19 16:57:31,121 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Execution is successful. 2013-08-19 16:57:31,122 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-1:null) Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config This is because the bridge name on old hosts are cloudVirBr110, and brem1-110 on new hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4225) [Automation] integration.component.test_snapshots failing with error 'TestSnapshots' object has no attribute 'template'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4225: -- Assignee: Rayees Namathponnan (was: Prasanna Santhanam) This is the same problem as CLOUDSTACK-4511. Something is changing your original KVM deployment config during your test run. [Automation] integration.component.test_snapshots failing with error 'TestSnapshots' object has no attribute 'template' - Key: CLOUDSTACK-4225 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4225 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.0 Environment: Automation Reporter: Rayees Namathponnan Assignee: Rayees Namathponnan Priority: Critical Fix For: 4.2.0 Test cases failed with below error 'TestSnapshots' object has no attribute 'config' begin captured logging testclient.testcase.TestSnapshots: DEBUG: Creating a Snapshot from data volume: 53efb886-b2f8-4420-af47-cb8017eb8f54 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_snapshots.py, line 354, in test_02_snapshot_data_disk self.assertTrue(self.is_snapshot_on_nfs(snapshot_uuid)) File /Repo_30X/ipcl/cloudstack/test/integration/component/test_snapshots.py, line 265, in is_snapshot_on_nfs (self.config.mgtSvr[0].mgtSvrIp, e)) 'TestSnapshots' object has no attribute 'config' begin captured logging testclient.testcase.TestSnapshots: DEBUG: Creating a Snapshot from data volume: 53efb886-b2f8-4420-af47-cb8017eb8f54 - end captured logging - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4511) [Automation] Test case smoke.test_routers:TestRouterServices failed due attribute 'config' in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4511: -- Assignee: Rayees Namathponnan (was: Prasanna Santhanam) Can you add some more investigation on this? I'm unable to reproduce this. Ideally, the property self.config is not dependant on the hypervisor. [Automation] Test case smoke.test_routers:TestRouterServices failed due attribute 'config' in KVM -- Key: CLOUDSTACK-4511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4511 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Reporter: Rayees Namathponnan Assignee: Rayees Namathponnan Test case fails after the last two check-in 4.2-forward branch https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=history;f=test/integration/smoke/test_routers.py;h=02686664ded049473346b407a60609fb8d149dee;hb=refs/heads/4.2-forward Test case failed with below error; issue observed in KVM env 'TestRouterServices' object has no attribute 'config' begin captured logging testclient.testcase.TestRouterServices: DEBUG: Restarting network with ID: 0cdb5da4-7d9f-49f8-9e41-9fa7c8c1e94a, Network state: Implemented - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/smoke/test_routers.py, line 488, in test_04_restart_network_wo_cleanup host.user, host.passwd = get_host_credentials(self.config, host.ipaddress) 'TestRouterServices' object has no attribute 'config' begin captured logging testclient.testcase.TestRouterServices: DEBUG: Restarting network with ID: 0cdb5da4-7d9f-49f8-9e41-9fa7c8c1e94a, Network state: Implemented - end captured logging - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4453: -- Assignee: Prasanna Santhanam Routers test use VM credentials as host credentials --- Key: CLOUDSTACK-4453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical In test_routers.py (in smoke and component) we do the following, result = get_process_status( host.ipaddress, self.services['virtual_machine'][publicport], self.vm_1.username, self.vm_1.password, router.linklocalip, service dnsmasq status ) In this case : host.ipaddress is the IP address of the XenServer host. self.services['virtual_machine'][publicport] is 22 (SSH port) self.vm_1.username / password are the username and password of the VM instance created for this test. The call that fails in get_process_status is this: ssh = remoteSSHClient(hostip, port, username, password) In this case it seems the test is trying to create a SSH connection to the XS host using the username / password of the VM instance (which will fail because the XS host has a different password) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4453. Resolution: Fixed Routers test use VM credentials as host credentials --- Key: CLOUDSTACK-4453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical In test_routers.py (in smoke and component) we do the following, result = get_process_status( host.ipaddress, self.services['virtual_machine'][publicport], self.vm_1.username, self.vm_1.password, router.linklocalip, service dnsmasq status ) In this case : host.ipaddress is the IP address of the XenServer host. self.services['virtual_machine'][publicport] is 22 (SSH port) self.vm_1.username / password are the username and password of the VM instance created for this test. The call that fails in get_process_status is this: ssh = remoteSSHClient(hostip, port, username, password) In this case it seems the test is trying to create a SSH connection to the XS host using the username / password of the VM instance (which will fail because the XS host has a different password) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam closed CLOUDSTACK-4453. -- http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_routers/776/ Routers test use VM credentials as host credentials --- Key: CLOUDSTACK-4453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical In test_routers.py (in smoke and component) we do the following, result = get_process_status( host.ipaddress, self.services['virtual_machine'][publicport], self.vm_1.username, self.vm_1.password, router.linklocalip, service dnsmasq status ) In this case : host.ipaddress is the IP address of the XenServer host. self.services['virtual_machine'][publicport] is 22 (SSH port) self.vm_1.username / password are the username and password of the VM instance created for this test. The call that fails in get_process_status is this: ssh = remoteSSHClient(hostip, port, username, password) In this case it seems the test is trying to create a SSH connection to the XS host using the username / password of the VM instance (which will fail because the XS host has a different password) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4303) [Automation] test_egress_fw_rules test cases failed to except script and tests failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4303: --- Component/s: Network Controller [Automation] test_egress_fw_rules test cases failed to except script and tests failed -- Key: CLOUDSTACK-4303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4303 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Infra, Network Controller Reporter: Rayees Namathponnan Assignee: Jayapal Reddy Priority: Critical Test cases from integration.component.test_egress_fw_rules.TestEgressFWRules fails test cases expecting script @ /tmp/expect_scrip, this should be handled in test case, Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py, line 51, in test_wrap_exception_log raise e Script result is ['bash: /tmp/expect_script.exp: /usr/bin/expect: bad interpreter: No such file or directory'] is not matching with ['100'] begin captured logging testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network offering: 0bd6212f-b34c-4f7a-a84f-0c172bee6ac8 testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: ef2626c2-6849-43e7-8418-0c89ed528d62 testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the account: test-SSFX20 testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: test-SSFX20 testclient.testcase.TestEgressFWRules: DEBUG: expect_script #!/usr/bin/expect spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.3.141 expect root@r-342-QA:~# send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.215 ping -c 1 www.google.com; exit $? expect root@10.1.1.215's password: send password interact expect_script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4303) [Automation] test_egress_fw_rules test cases failed to except script and tests failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4303: -- Assignee: Jayapal Reddy (was: Prasanna Santhanam) Hey Jayapal, can you take a quick look to see if this a failure in CS? [Automation] test_egress_fw_rules test cases failed to except script and tests failed -- Key: CLOUDSTACK-4303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4303 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Infra Reporter: Rayees Namathponnan Assignee: Jayapal Reddy Priority: Critical Test cases from integration.component.test_egress_fw_rules.TestEgressFWRules fails test cases expecting script @ /tmp/expect_scrip, this should be handled in test case, Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py, line 51, in test_wrap_exception_log raise e Script result is ['bash: /tmp/expect_script.exp: /usr/bin/expect: bad interpreter: No such file or directory'] is not matching with ['100'] begin captured logging testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network offering: 0bd6212f-b34c-4f7a-a84f-0c172bee6ac8 testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: ef2626c2-6849-43e7-8418-0c89ed528d62 testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the account: test-SSFX20 testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: test-SSFX20 testclient.testcase.TestEgressFWRules: DEBUG: expect_script #!/usr/bin/expect spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.3.141 expect root@r-342-QA:~# send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.215 ping -c 1 www.google.com; exit $? expect root@10.1.1.215's password: send password interact expect_script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4499) Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4499: --- Component/s: XenServer Management Server API Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost -- Key: CLOUDSTACK-4499 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4499 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server, XenServer Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical The same bug was reported in CLOUDSTACK-3839 which has been determined to be a UI issue but the problem is with the addHost API and Xenserver hosts 6.1/6.2. When a freshly provisioned 6.1/6.2 host is added to cloudstack it initially goes into 'Alert' state thereby failing the storage pool creation subsequently. StoragePool addition requires the hosts to be in Up state. But a minute or two later the Xenserver host automatically moves back to Up state after which storage pool addition can occur When the host is added to cloudstack: 2013-08-26 06:46:22,965 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-1:null) Seq 1-1916403719: Executing request 2013-08-26 06:46:23,261 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Can't find a vif on dom0 for link local, creating a new one 2013-08-26 06:46:23,274 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Lowest available Vif device number: 0 for VM: Control domain on host: apache-81-3 2013-08-26 06:46:23,600 WARN [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Unable to create local link network The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.xensource.xenapi.Types.checkResponse(Types.java:1694) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VIF.plug(VIF.java:846) Host marked Alert: 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.network.NetworkUsageManagerImpl$DirectNetworkStatsListener 2013-08-26 06:46:23,616 DEBUG [cloud.network.NetworkUsageManagerImpl] (catalina-exec-14:null) Disconnected called on 1 with status Alert 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.consoleproxy.ConsoleProxyListener 2013-08-26 06:46:23,619 DEBUG [cloud.host.Status] (catalina-exec-14:null) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = apache-81-3] 2013-08-26 06:46:23,625 DEBUG [cloud.host.Status] (catalina-exec-14:null) Agent status update: [id = 1; name = apache-81-3; old status = Connecting; event = AgentDisconnected; new status = Alert; old update count = 1; new update count = 2] Automatic retry by CloudStack a few moments later: 2013-08-26 06:46:52,752 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager Timer:null) Completed acquiring hosts for clusters not owned by any management server 2013-08-26 06:46:52,756 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Found 2 unmanaged direct hosts, processing connect for them... 2013-08-26 06:46:52,757 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 1(apache-81-3) Meanwhile Storage Pool addition fails: 2013-08-26 06:46:52,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===END=== 10.208.8.5 -- GET username=rootapiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwpodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96hypervisor=XenServerclusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=addHosturl=http%3A%2F%2Fapache-81-2signature=oJqOno9flCtPMSSHH%2FZD%2BJl5QXw%3Dresponse=json 2013-08-26 06:46:52,773 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) ===START=== 10.208.8.5 -- GET apiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwname=z0p0c0ps0url=nfs%3A%2F%2Fnfs.fmt.vmops.com%3A%2Fexport%2Fautomation%2Facs%2Fprimarypodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96clusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=createStoragePoolsignature=70CuFbmf58PU4X0QbF1tKbBGT60%3Dresponse=json
[jira] [Created] (CLOUDSTACK-4499) Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost
Prasanna Santhanam created CLOUDSTACK-4499: -- Summary: Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost Key: CLOUDSTACK-4499 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4499 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical The same bug was reported in CLOUDSTACK-3839 which has been determined to be a UI issue but the problem is with the addHost API and Xenserver hosts 6.1/6.2. When a freshly provisioned 6.1/6.2 host is added to cloudstack it initially goes into 'Alert' state thereby failing the storage pool creation subsequently. StoragePool addition requires the hosts to be in Up state. But a minute or two later the Xenserver host automatically moves back to Up state after which storage pool addition can occur When the host is added to cloudstack: 2013-08-26 06:46:22,965 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-1:null) Seq 1-1916403719: Executing request 2013-08-26 06:46:23,261 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Can't find a vif on dom0 for link local, creating a new one 2013-08-26 06:46:23,274 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Lowest available Vif device number: 0 for VM: Control domain on host: apache-81-3 2013-08-26 06:46:23,600 WARN [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Unable to create local link network The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.xensource.xenapi.Types.checkResponse(Types.java:1694) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VIF.plug(VIF.java:846) Host marked Alert: 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.network.NetworkUsageManagerImpl$DirectNetworkStatsListener 2013-08-26 06:46:23,616 DEBUG [cloud.network.NetworkUsageManagerImpl] (catalina-exec-14:null) Disconnected called on 1 with status Alert 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.consoleproxy.ConsoleProxyListener 2013-08-26 06:46:23,619 DEBUG [cloud.host.Status] (catalina-exec-14:null) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = apache-81-3] 2013-08-26 06:46:23,625 DEBUG [cloud.host.Status] (catalina-exec-14:null) Agent status update: [id = 1; name = apache-81-3; old status = Connecting; event = AgentDisconnected; new status = Alert; old update count = 1; new update count = 2] Automatic retry by CloudStack a few moments later: 2013-08-26 06:46:52,752 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager Timer:null) Completed acquiring hosts for clusters not owned by any management server 2013-08-26 06:46:52,756 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Found 2 unmanaged direct hosts, processing connect for them... 2013-08-26 06:46:52,757 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 1(apache-81-3) Meanwhile Storage Pool addition fails: 2013-08-26 06:46:52,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===END=== 10.208.8.5 -- GET username=rootapiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwpodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96hypervisor=XenServerclusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=addHosturl=http%3A%2F%2Fapache-81-2signature=oJqOno9flCtPMSSHH%2FZD%2BJl5QXw%3Dresponse=json 2013-08-26 06:46:52,773 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) ===START=== 10.208.8.5 -- GET apiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwname=z0p0c0ps0url=nfs%3A%2F%2Fnfs.fmt.vmops.com%3A%2Fexport%2Fautomation%2Facs%2Fprimarypodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96clusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=createStoragePoolsignature=70CuFbmf58PU4X0QbF1tKbBGT60%3Dresponse=json 2013-08-26 06:46:52,787 DEBUG [cloud.network.NetworkModelImpl] (ClusteredAgentManager Timer:null) Failed to retrive the default label for storage traffic:zone: 1 hypervisor: XenServer due to:Unable to find the default physical network with traffic=Storage in the specified zone id 2013-08-26 06:46:52,839 DEBUG [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl] (catalina-exec-16:null) createPool Params @ scheme -
[jira] [Updated] (CLOUDSTACK-4499) Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4499: --- Affects Version/s: 4.2.0 Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost -- Key: CLOUDSTACK-4499 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4499 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical The same bug was reported in CLOUDSTACK-3839 which has been determined to be a UI issue but the problem is with the addHost API and Xenserver hosts 6.1/6.2. When a freshly provisioned 6.1/6.2 host is added to cloudstack it initially goes into 'Alert' state thereby failing the storage pool creation subsequently. StoragePool addition requires the hosts to be in Up state. But a minute or two later the Xenserver host automatically moves back to Up state after which storage pool addition can occur When the host is added to cloudstack: 2013-08-26 06:46:22,965 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-1:null) Seq 1-1916403719: Executing request 2013-08-26 06:46:23,261 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Can't find a vif on dom0 for link local, creating a new one 2013-08-26 06:46:23,274 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Lowest available Vif device number: 0 for VM: Control domain on host: apache-81-3 2013-08-26 06:46:23,600 WARN [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Unable to create local link network The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.xensource.xenapi.Types.checkResponse(Types.java:1694) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VIF.plug(VIF.java:846) Host marked Alert: 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.network.NetworkUsageManagerImpl$DirectNetworkStatsListener 2013-08-26 06:46:23,616 DEBUG [cloud.network.NetworkUsageManagerImpl] (catalina-exec-14:null) Disconnected called on 1 with status Alert 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.consoleproxy.ConsoleProxyListener 2013-08-26 06:46:23,619 DEBUG [cloud.host.Status] (catalina-exec-14:null) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = apache-81-3] 2013-08-26 06:46:23,625 DEBUG [cloud.host.Status] (catalina-exec-14:null) Agent status update: [id = 1; name = apache-81-3; old status = Connecting; event = AgentDisconnected; new status = Alert; old update count = 1; new update count = 2] Automatic retry by CloudStack a few moments later: 2013-08-26 06:46:52,752 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager Timer:null) Completed acquiring hosts for clusters not owned by any management server 2013-08-26 06:46:52,756 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Found 2 unmanaged direct hosts, processing connect for them... 2013-08-26 06:46:52,757 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 1(apache-81-3) Meanwhile Storage Pool addition fails: 2013-08-26 06:46:52,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===END=== 10.208.8.5 -- GET username=rootapiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwpodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96hypervisor=XenServerclusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=addHosturl=http%3A%2F%2Fapache-81-2signature=oJqOno9flCtPMSSHH%2FZD%2BJl5QXw%3Dresponse=json 2013-08-26 06:46:52,773 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) ===START=== 10.208.8.5 -- GET apiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwname=z0p0c0ps0url=nfs%3A%2F%2Fnfs.fmt.vmops.com%3A%2Fexport%2Fautomation%2Facs%2Fprimarypodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96clusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=createStoragePoolsignature=70CuFbmf58PU4X0QbF1tKbBGT60%3Dresponse=json 2013-08-26 06:46:52,787 DEBUG [cloud.network.NetworkModelImpl] (ClusteredAgentManager Timer:null) Failed to
[jira] [Updated] (CLOUDSTACK-4499) Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4499: --- Attachment: mslog.tar.bz2 cloud.sql.tar.bz2 management server log and database dump. The issue is consistently reproducible on xenservers 6.1 and 6.2 Xen6.1/Xen6.2 hosts initially transition to 'Alert' and then to 'Up' after addHost -- Key: CLOUDSTACK-4499 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4499 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server, XenServer Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Priority: Critical Attachments: cloud.sql.tar.bz2, mslog.tar.bz2 The same bug was reported in CLOUDSTACK-3839 which has been determined to be a UI issue but the problem is with the addHost API and Xenserver hosts 6.1/6.2. When a freshly provisioned 6.1/6.2 host is added to cloudstack it initially goes into 'Alert' state thereby failing the storage pool creation subsequently. StoragePool addition requires the hosts to be in Up state. But a minute or two later the Xenserver host automatically moves back to Up state after which storage pool addition can occur When the host is added to cloudstack: 2013-08-26 06:46:22,965 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-1:null) Seq 1-1916403719: Executing request 2013-08-26 06:46:23,261 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Can't find a vif on dom0 for link local, creating a new one 2013-08-26 06:46:23,274 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Lowest available Vif device number: 0 for VM: Control domain on host: apache-81-3 2013-08-26 06:46:23,600 WARN [xen.resource.CitrixResourceBase] (DirectAgent-1:null) Unable to create local link network The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.xensource.xenapi.Types.checkResponse(Types.java:1694) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VIF.plug(VIF.java:846) Host marked Alert: 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.network.NetworkUsageManagerImpl$DirectNetworkStatsListener 2013-08-26 06:46:23,616 DEBUG [cloud.network.NetworkUsageManagerImpl] (catalina-exec-14:null) Disconnected called on 1 with status Alert 2013-08-26 06:46:23,616 DEBUG [agent.manager.AgentManagerImpl] (catalina-exec-14:null) Sending Disconnect to listener: com.cloud.consoleproxy.ConsoleProxyListener 2013-08-26 06:46:23,619 DEBUG [cloud.host.Status] (catalina-exec-14:null) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = apache-81-3] 2013-08-26 06:46:23,625 DEBUG [cloud.host.Status] (catalina-exec-14:null) Agent status update: [id = 1; name = apache-81-3; old status = Connecting; event = AgentDisconnected; new status = Alert; old update count = 1; new update count = 2] Automatic retry by CloudStack a few moments later: 2013-08-26 06:46:52,752 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager Timer:null) Completed acquiring hosts for clusters not owned by any management server 2013-08-26 06:46:52,756 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Found 2 unmanaged direct hosts, processing connect for them... 2013-08-26 06:46:52,757 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 1(apache-81-3) Meanwhile Storage Pool addition fails: 2013-08-26 06:46:52,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===END=== 10.208.8.5 -- GET username=rootapiKey=sLUjl2n1c33JJpY4ZzMtObUgp9Ah2xW5inofCclZQQ1V6xp5k3CmAsGhemLwQxVvQY67EiopM_fbWBoJRKCIwwpodid=fdf30680-d5c7-425e-bd7f-fb8c52e7cb96hypervisor=XenServerclusterid=10ff9a88-54bc-405b-9b4b-c26acf9caca8zoneid=0431023e-ff78-43b6-a32d-262f36a78cbbcommand=addHosturl=http%3A%2F%2Fapache-81-2signature=oJqOno9flCtPMSSHH%2FZD%2BJl5QXw%3Dresponse=json 2013-08-26 06:46:52,773 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) ===START=== 10.208.8.5 -- GET
[jira] [Created] (CLOUDSTACK-4473) Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment'
Prasanna Santhanam created CLOUDSTACK-4473: -- Summary: Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment' Key: CLOUDSTACK-4473 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4473 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical integration.smoke.test_nic.TestNic.test_01_nic (from nosetests) Failing for the past 5 builds (Since Unstable#762 ) Took 1 min 15 sec. add description Error Message Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_nic/test/integration/smoke/test_nic.py, line 367, in test_01_nic self.assertEqual(True, False, Exception during NIC test!: + str(ex)) File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4473) Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4473: -- Assignee: Prasanna Santhanam Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment' - Key: CLOUDSTACK-4473 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4473 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical integration.smoke.test_nic.TestNic.test_01_nic (from nosetests) Failing for the past 5 builds (Since Unstable#762 ) Took 1 min 15 sec. add description Error Message Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_nic/test/integration/smoke/test_nic.py, line 367, in test_01_nic self.assertEqual(True, False, Exception during NIC test!: + str(ex)) File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4473) Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam closed CLOUDSTACK-4473. -- Verified against simulator Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment' - Key: CLOUDSTACK-4473 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4473 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical integration.smoke.test_nic.TestNic.test_01_nic (from nosetests) Failing for the past 5 builds (Since Unstable#762 ) Took 1 min 15 sec. add description Error Message Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_nic/test/integration/smoke/test_nic.py, line 367, in test_01_nic self.assertEqual(True, False, Exception during NIC test!: + str(ex)) File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4473) Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4473. Resolution: Fixed Test Nic fails with 'Exception during NIC testlocal variable 'allow_egress' referenced before assignment' - Key: CLOUDSTACK-4473 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4473 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical integration.smoke.test_nic.TestNic.test_01_nic (from nosetests) Failing for the past 5 builds (Since Unstable#762 ) Took 1 min 15 sec. add description Error Message Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_nic/test/integration/smoke/test_nic.py, line 367, in test_01_nic self.assertEqual(True, False, Exception during NIC test!: + str(ex)) File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Exception during NIC test!: local variable 'allow_egress' referenced before assignment test_01_nic (integration.smoke.test_nic.TestNic): DEBUG: Exception during NIC test!: local variable 'allow_egress' referenced before assignment -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2425) fix test_network script for the BVT failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-2425: --- Issue Type: Test (was: Bug) fix test_network script for the BVT failures Key: CLOUDSTACK-2425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2425 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.2.0 Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Fix For: 4.2.0 fix test_network script for the BVT failures -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2471) test_host_high_availability.py refers to non-existent library method wait_for_vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-2471: -- Assignee: Prasanna Santhanam test_host_high_availability.py refers to non-existent library method wait_for_vm Key: CLOUDSTACK-2471 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2471 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Fix For: 4.2.0 test_host_high_availability.py: #verify the VM live migration happened to another running host self.debug(Waiting for VM to come up) wait_for_vm( --does not exist in common.py self.apiclient, virtualmachineid=vm_with_ha_disabled.id, interval=timeout ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials
Prasanna Santhanam created CLOUDSTACK-4453: -- Summary: Routers test use VM credentials as host credentials Key: CLOUDSTACK-4453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical In test_routers.py (in smoke and component) we do the following, result = get_process_status( host.ipaddress, self.services['virtual_machine'][publicport], self.vm_1.username, self.vm_1.password, router.linklocalip, service dnsmasq status ) In this case : host.ipaddress is the IP address of the XenServer host. self.services['virtual_machine'][publicport] is 22 (SSH port) self.vm_1.username / password are the username and password of the VM instance created for this test. The call that fails in get_process_status is this: ssh = remoteSSHClient(hostip, port, username, password) In this case it seems the test is trying to create a SSH connection to the XS host using the username / password of the VM instance (which will fail because the XS host has a different password) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4256) [Automation] TestSharedNetworks test cases failed while creating network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4256: -- Assignee: (was: Prasanna Santhanam) The feature's design has been altered as part of CLOUDSTACK-4282. Previously one would be allowed to create overlapping CIDRs with different VLANs. This is not allowed now. The SharedNetwork suite needs to be revisited after a revamp of the test plan for shared networks. I'm not sure how much of a regression this would be for existing users to disallow overlapping cidrs. Please see original bug for comments. [Automation] TestSharedNetworks test cases failed while creating network - Key: CLOUDSTACK-4256 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4256 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.2.0 Below test cases failed integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_accountSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_domainSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_projectSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 integration.component.test_shared_networks.TestSharedNetworks.test_deployVM_isolatedAndShared integration.component.test_shared_networks.TestSharedNetworks.test_deployVM_multipleSharedNetwork Test cases failed while creating network\, observed below error Error Message Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:There is a isolated/shared network with vlan id: 1200 already exists in zone 1 begin captured logging testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created: admin-XABU1-Q7G53T testclient.testcase.TestSharedNetworks: DEBUG: User type account created: admin-XABU1-1Q3UHH testclient.testcase.TestSharedNetworks: DEBUG: Physical Network found: 4b414b4e-8e90-4ef4-9e33-eb56970cd30f testclient.testcase.TestSharedNetworks: DEBUG: Shared Network Offering created: 699901f7-083a-41f7-96f0-6ee88d05ae78 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1030, in test_createSharedNetwork_accountSpecific zoneid=self.zone.id File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 1940, in create return Network(apiclient.createNetwork(cmd).__dict__) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1709, in createNetwork response = self.connection.marvin_request(command, response_type=response, method=method) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:There is a isolated/shared network with vlan id: 1200 already exists in zone 1 begin captured logging testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created: admin-XABU1-Q7G53T testclient.testcase.TestSharedNetworks: DEBUG: User type account created: admin-XABU1-1Q3UHH testclient.testcase.TestSharedNetworks: DEBUG: Physical Network found: 4b414b4e-8e90-4ef4-9e33-eb56970cd30f testclient.testcase.TestSharedNetworks: DEBUG: Shared Network Offering created: 699901f7-083a-41f7-96f0-6ee88d05ae78 - end captured logging - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4309) [Automation] TestVMPasswordEnabled.test_11_get_vm_password failed during ssh connection
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasanna Santhanam reassigned CLOUDSTACK-4309:
--
Assignee: Rayees Namathponnan (was: Srikanteswararao Talluri)
Can you attach logs of your test?
[Automation] TestVMPasswordEnabled.test_11_get_vm_password failed during ssh
connection
---
Key: CLOUDSTACK-4309
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4309
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.2.0
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Fix For: 4.2.0
Test cases
integration.component.test_vm_passwdenabled.TestVMPasswordEnabled.test_11_get_vm_password
failed with below error
SSH into VM: 10.223.122.79 failed
begin captured logging
paramiko.transport: DEBUG: starting thread (client mode): 0xe944290L
paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server
key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1',
'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96',
'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160',
'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
compress:['none', 'z...@openssh.com'] server compress:['none',
'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False
paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key
type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local
hmac-sha1, remote hmac-sha1; compression: local none, remote none
paramiko.transport: DEBUG: Switch to new keys ...
paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.122.68:
0f8b3ff9dc4dce10340227dab3cac032
paramiko.transport: DEBUG: Trying discovered key
76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa
paramiko.transport: DEBUG: userauth is OK
paramiko.transport: INFO: Authentication (publickey) failed.
paramiko.transport: DEBUG: userauth is OK
paramiko.transport: INFO: Authentication (password) successful!
sshClient: DEBUG: SSH connect: root@10.223.122.68 with passwd password
paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
paramiko.transport: INFO: Secsh channel 1 opened.
paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
paramiko.transport: DEBUG: [chan 1] EOF received (1)
sshClient: DEBUG: {Cmd: cd /etc/init.d;wget
http://people.apache.org/~tsp/cloud-set-guest-password via Host:
10.223.122.68} {returns: ['--2013-08-13 06:01:11--
http://people.apache.org/~tsp/cloud-set-guest-password', 'Resolving
people.apache.org... 140.211.11.9', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:04:31-- (try: 2)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:07:42-- (try: 3)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:10:54-- (try: 4)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:14:07-- (try: 5)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:17:21-- (try: 6)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
people.apache.org|140.211.11.9|:80... failed: Connection timed out.',
'Retrying.', '', '--2013-08-13 06:20:36-- (try: 7)
http://people.apache.org/~tsp/cloud-set-guest-password', 'Connecting to
[jira] [Assigned] (CLOUDSTACK-4466) DHCP capability breaks in 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4466: -- Assignee: Dave Cahill Just assigning this over to you since you've submitted the patch. DHCP capability breaks in 4.2 - Key: CLOUDSTACK-4466 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4466 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.2.0 Reporter: Dave Cahill Assignee: Dave Cahill Fix For: 4.2.0 Prior to this change, the default capabilities for DHCP list was null. https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=956a2a68cebc1b4427bc20ff0e7790ef9846893c The change causes a NullPointerException if the DHCP capabilities list is null. The change replaces null in the VirtualRouterElement to avoid the NPE, but leaves other elements which were using null for the DHCP capabilities list broken. This causes an NPE and failure to implement DHCP. From a quick code grep, it looks like MidoNet is the only network plugin affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4418) Tests doing operations within guests post VirtualMachine.create w. default network offering fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4418: -- Assignee: Prasanna Santhanam Tests doing operations within guests post VirtualMachine.create w. default network offering fail Key: CLOUDSTACK-4418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4418 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical Tests typically will call on VirtualMachine.create() with no networkids passed. In such cases the VM is deployed using a network created by the Default offerings (Isolated with SourceNAT). These offerings with 4.2 by default DENY all outgoing traffic until egress rules are added to allow access. This causes all tests doing deployVM without networkid to fail when there are guest operations like wget done within the VMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4418) Tests doing operations within guests post VirtualMachine.create w. default network offering fail
Prasanna Santhanam created CLOUDSTACK-4418: -- Summary: Tests doing operations within guests post VirtualMachine.create w. default network offering fail Key: CLOUDSTACK-4418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4418 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Tests typically will call on VirtualMachine.create() with no networkids passed. In such cases the VM is deployed using a network created by the Default offerings (Isolated with SourceNAT). These offerings with 4.2 by default DENY all outgoing traffic until egress rules are added to allow access. This causes all tests doing deployVM without networkid to fail when there are guest operations like wget done within the VMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
