[jira] [Resolved] (CLOUDSTACK-7441) [Automation] Fix the script "test_resource_limits.py" - Templates are registered as admin's

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye resolved CLOUDSTACK-7441.

Resolution: Fixed

> [Automation] Fix the script "test_resource_limits.py" - Templates are 
> registered as admin's
> ---
>
> Key: CLOUDSTACK-7441
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7441
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Two test cases are failing in the test suite: *test_05_templates_per_account* 
> & *test_05_templates_per_domain*
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 1355, in test_05_templates_per_domain
> domainid=self.account.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Bug Information in the Client result logs:*
> {code}
> ==
> FAIL: Test Templates limit per account
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
> AssertionError: Exception not raised
>  >> begin captured stdout << -
> === TestName: test_05_templates_per_account | Status : FAILED ===
> .
> .
> .
> .
> test_05_templates_per_account 
> (integration.component.test_resource_limits.TestResourceLimitsAccount): 
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-08-24T14:19:11+', 
> jobresult : {domain : u'ROOT', domainid : 
> u'56ab18f0-2b4d-11e4-89bd-1e5d0e053e75', ostypename : u'CentOS 5.3 (64-bit)', 
> zoneid : u'eb811e7d-59d4-4c72-a965-80d9e30572d1', displaytext : u'Cent OS 
> Template', ostypeid : u'56b1e2f2-2b4d-11e4-89bd-1e5d0e053e75', 
> passwordenabled : False, id : u'c406715b-aa97-4361-a212-32cdfba76b00', size : 
> 21474836480, isready : True, format : u'VHD', templatetype : u'USER', details 
> : {platform : u'viridian:true;acpi:1;apic:true;pae:true;nx:true', 
> Message.ReservedCapacityFreed.Flag : u'false'}, zonename : u'XenRT-Zone-0', 
> status : u'Download Complete', isdynamicallyscalable : False, tags : [], 
> isfeatured : False, sshkeyenabled : False, account : u'admin', isextractable 
> : True, crossZones : False, sourcetemplateid : 
> u'56af8f20-2b4d-11e4-89bd-1e5d0e053e75', name : u'Cent OS Template-LS47A4', 
> created : u'2014-08-24T14:19:11+', hypervisor : u'XenServer', ispublic : 
> False}, cmd : 
> u'org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin', 
> userid : u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 1, jobid : 
> u'e9295a94-4dfd-4c27-a405-fab4975f0eee', jobresultcode : 0, jobinstanceid : 
> u'c406715b-aa97-4361-a212-32cdfba76b00', jobresulttype : u'object', 
> jobinstancetype : u'Template', accountid : 
> u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}
> test_05_templates_per_account 
> (integration.component.test_resource_limits.TestResourceLimitsAccount): 
> DEBUG: ===Jobid:e9295a94-4dfd-4c27-a405-fab4975f0eee ; StartTime:Sun Aug 24 
> 14:19:12 2014 ; EndTime:Sun Aug 24 14:20:52 2014 ; TotalTime:-100===
> test_05_templates_per_account 
> (integration.component.test_resource_limits.T

[jira] [Commented] (CLOUDSTACK-7441) [Automation] Fix the script "test_resource_limits.py" - Templates are registered as admin's

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119459#comment-14119459
 ] 

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

Commit 396f29c135e3f384218400a1f64c63a6dbb2a76d in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=396f29c ]

CLOUDSTACK-7441: Fixed tempalte register issue in test_resource_limits.py

Signed-off-by: SrikanteswaraRao Talluri 


> [Automation] Fix the script "test_resource_limits.py" - Templates are 
> registered as admin's
> ---
>
> Key: CLOUDSTACK-7441
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7441
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Two test cases are failing in the test suite: *test_05_templates_per_account* 
> & *test_05_templates_per_domain*
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 1355, in test_05_templates_per_domain
> domainid=self.account.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Bug Information in the Client result logs:*
> {code}
> ==
> FAIL: Test Templates limit per account
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
> AssertionError: Exception not raised
>  >> begin captured stdout << -
> === TestName: test_05_templates_per_account | Status : FAILED ===
> .
> .
> .
> .
> test_05_templates_per_account 
> (integration.component.test_resource_limits.TestResourceLimitsAccount): 
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-08-24T14:19:11+', 
> jobresult : {domain : u'ROOT', domainid : 
> u'56ab18f0-2b4d-11e4-89bd-1e5d0e053e75', ostypename : u'CentOS 5.3 (64-bit)', 
> zoneid : u'eb811e7d-59d4-4c72-a965-80d9e30572d1', displaytext : u'Cent OS 
> Template', ostypeid : u'56b1e2f2-2b4d-11e4-89bd-1e5d0e053e75', 
> passwordenabled : False, id : u'c406715b-aa97-4361-a212-32cdfba76b00', size : 
> 21474836480, isready : True, format : u'VHD', templatetype : u'USER', details 
> : {platform : u'viridian:true;acpi:1;apic:true;pae:true;nx:true', 
> Message.ReservedCapacityFreed.Flag : u'false'}, zonename : u'XenRT-Zone-0', 
> status : u'Download Complete', isdynamicallyscalable : False, tags : [], 
> isfeatured : False, sshkeyenabled : False, account : u'admin', isextractable 
> : True, crossZones : False, sourcetemplateid : 
> u'56af8f20-2b4d-11e4-89bd-1e5d0e053e75', name : u'Cent OS Template-LS47A4', 
> created : u'2014-08-24T14:19:11+', hypervisor : u'XenServer', ispublic : 
> False}, cmd : 
> u'org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin', 
> userid : u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 1, jobid : 
> u'e9295a94-4dfd-4c27-a405-fab4975f0eee', jobresultcode : 0, jobinstanceid : 
> u'c406715b-aa97-4361-a212-32cdfba76b00', jobresulttype : u'object', 
> jobinstancetype : u'Template', accountid : 
> u'77df055e

[jira] [Updated] (CLOUDSTACK-7441) [Automation] Fix the script "test_resource_limits.py" - Templates are registered as admin's

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7441:
---
Status: Reviewable  (was: In Progress)

> [Automation] Fix the script "test_resource_limits.py" - Templates are 
> registered as admin's
> ---
>
> Key: CLOUDSTACK-7441
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7441
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Two test cases are failing in the test suite: *test_05_templates_per_account* 
> & *test_05_templates_per_domain*
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Error Message*
> Exception not raised   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 1355, in test_05_templates_per_domain
> domainid=self.account.domainid,
>   File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> 'Exception not raised\n
> Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=resource_limits
>
> *Bug Information in the Client result logs:*
> {code}
> ==
> FAIL: Test Templates limit per account
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/component/test_resource_limits.py", 
> line 844, in test_05_templates_per_account
> domainid=self.account_1.domainid,
> AssertionError: Exception not raised
>  >> begin captured stdout << -
> === TestName: test_05_templates_per_account | Status : FAILED ===
> .
> .
> .
> .
> test_05_templates_per_account 
> (integration.component.test_resource_limits.TestResourceLimitsAccount): 
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-08-24T14:19:11+', 
> jobresult : {domain : u'ROOT', domainid : 
> u'56ab18f0-2b4d-11e4-89bd-1e5d0e053e75', ostypename : u'CentOS 5.3 (64-bit)', 
> zoneid : u'eb811e7d-59d4-4c72-a965-80d9e30572d1', displaytext : u'Cent OS 
> Template', ostypeid : u'56b1e2f2-2b4d-11e4-89bd-1e5d0e053e75', 
> passwordenabled : False, id : u'c406715b-aa97-4361-a212-32cdfba76b00', size : 
> 21474836480, isready : True, format : u'VHD', templatetype : u'USER', details 
> : {platform : u'viridian:true;acpi:1;apic:true;pae:true;nx:true', 
> Message.ReservedCapacityFreed.Flag : u'false'}, zonename : u'XenRT-Zone-0', 
> status : u'Download Complete', isdynamicallyscalable : False, tags : [], 
> isfeatured : False, sshkeyenabled : False, account : u'admin', isextractable 
> : True, crossZones : False, sourcetemplateid : 
> u'56af8f20-2b4d-11e4-89bd-1e5d0e053e75', name : u'Cent OS Template-LS47A4', 
> created : u'2014-08-24T14:19:11+', hypervisor : u'XenServer', ispublic : 
> False}, cmd : 
> u'org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin', 
> userid : u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 1, jobid : 
> u'e9295a94-4dfd-4c27-a405-fab4975f0eee', jobresultcode : 0, jobinstanceid : 
> u'c406715b-aa97-4361-a212-32cdfba76b00', jobresulttype : u'object', 
> jobinstancetype : u'Template', accountid : 
> u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}
> test_05_templates_per_account 
> (integration.component.test_resource_limits.TestResourceLimitsAccount): 
> DEBUG: ===Jobid:e9295a94-4dfd-4c27-a405-fab4975f0eee ; StartTime:Sun Aug 24 
> 14:19:12 2014 ; EndTime:Sun Aug 24 14:20:52 2014 ; TotalTime:-100===
> test_05_templates_per_account 
> (integration.component.tes

[jira] [Commented] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error

[Rayees Namathponnan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119442#comment-14119442
 ] 

Rayees Namathponnan commented on CLOUDSTACK-7474:
-

Submitted patch for review

> Failed to start MS with java7 version mismatch error
> 
>
> Key: CLOUDSTACK-7474
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps  to reproduce 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> Result 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start with below error 
> SEVERE: Null component 
> Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
> Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory
> SEVERE: Error deploying web application directory client
> java.lang.UnsupportedClassVersionError: 
> org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : 
> Unsupported major.minor version 51.0 (unable to load class 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
> at 
> org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
> at 
> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074)
> at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4377)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
> Default JAva version in this machcne is java6,  while start MS, we need to 
> pick java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME
> We need to fix this in classpath.conf
> export CLASSPATH
> if   [[ ! -d "$JAVA_HOME" && -d /usr/lib/jvm/jre-1.7.0 ]]; then
>  export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
> fi
> PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH
> export PATH 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing

[shweta agarwal (JIRA)]

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

shweta agarwal updated CLOUDSTACK-7473:
---
Attachment: ms.tar.gz
agent.log.tar.gz

> [LXC]putting host into maintenance is failing 
> --
>
> Key: CLOUDSTACK-7473
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Blocker
> Attachments: agent.log.tar.gz, ms.tar.gz
>
>
> Repro stesp:
> 1. create a zone with a LXC cluster having 2 host
> 2. create few LXC vms
> 3. Put one host into maintenance which has some VM  running
> Bug:
> Putting host into maintenance will never pass. host will remain in preparing 
> for maintenance stage and then goes to disconnect state.
> Agent log shows :
> 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-1:null) Failed to execute while migrating domain: 
> org.libvirt.LibvirtException: this function is not supported by the 
> connection driver: virDomainMigrate2
> 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent] 
> (agentRequest-Handler-1:null) Seq 1-3693233169420517550:  { Ans: , MgmtId: 
> 233845178472723, via: 1, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
>  this function is not supported by the connection driver: 
> virDomainMigrate2","wait":0}}] }
> 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent] 
> (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551:  { Cmd , 
> MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.MigrateCommand":{"vmName":"i-2-7-VM","destIp":"10.147.28.49","hostGuid":"2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource","isWindows":false,"vmTO":{"id":7,"name":"i-2-7-VM","type":"User","cpus":1,"minSpeed":128,"maxSpeed":128,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Red
>  Hat Enterprise Linux 
> 7.0","platformEmulator":"Other","bootArgs":"","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"QY0cKnTfogzaS49R283f1g==","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"caf07a92-9f6c-49df-a7e4-27289e715448","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"981fe152-6ee5--ae41-474736c881cf","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-7","size":647321600,"path":"981fe152-6ee5--ae41-474736c881cf","volumeId":7,"vmName":"i-2-7-VM","accountId":2,"format":"DIR","provisioningType":"THIN","id":7,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"981fe152-6ee5--ae41-474736c881cf","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"647321600"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"95826449-4163-46b8-91b7-8bf94f19ab8e","uuid":"d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f","ip":"10.147.30.166","netmask":"255.255.255.0","gateway":"10.147.30.1","mac":"06:54:96:00:00:07","dns1":"10.140.50.6","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://30","isolationUri":"vlan://30","isSecurityGroupEnabled":true}]},"executeInSequence":false,"wait":0}}]
>  }
> 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent] 
> (agentRequest-Handler-4:null) Processing command: 
> com.cloud.agent.api.MigrateCommand
> 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection] 
> (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM, 
> continue
> 2014-09-02 19:08:13,018 INFO  [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
> 2014-09-02 19:08:13,103 INFO  [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete, 
> waited 1000ms
> 2014-09-02 19:08:13,118 INFO  [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
> 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-4:null) Failed to execute while migrating domain: 
> org.libvirt.LibvirtEx

[jira] [Updated] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7474:

Assignee: Rayees Namathponnan

> Failed to start MS with java7 version mismatch error
> 
>
> Key: CLOUDSTACK-7474
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps  to reproduce 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> Result 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start with below error 
> SEVERE: Null component 
> Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
> Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory
> SEVERE: Error deploying web application directory client
> java.lang.UnsupportedClassVersionError: 
> org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : 
> Unsupported major.minor version 51.0 (unable to load class 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
> at 
> org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
> at 
> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074)
> at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4377)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
> Default JAva version in this machcne is java6,  while start MS, we need to 
> pick java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME
> We need to fix this in classpath.conf
> export CLASSPATH
> if   [[ ! -d "$JAVA_HOME" && -d /usr/lib/jvm/jre-1.7.0 ]]; then
>  export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
> fi
> PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH
> export PATH 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error

[Rayees Namathponnan (JIRA)]

Rayees Namathponnan created CLOUDSTACK-7474:
---

 Summary: Failed to start MS with java7 version mismatch error
 Key: CLOUDSTACK-7474
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
 Fix For: 4.5.0


Steps  to reproduce 

Step 1: Deploy new RHEL 6.3 machine
Step 2 : Install MS
Step 3: run deploy script and start MS

Result 

Installation completed successfully,  both java7 and java got installed as part 
of MS installation, but MS failed to start with below error 

SEVERE: Null component 
Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory
SEVERE: Error deploying web application directory client
java.lang.UnsupportedClassVersionError: 
org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : 
Unsupported major.minor version 51.0 (unable to load class 
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
at 
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335)
at 
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
at 
org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
at 
org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
at 
org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
at 
org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4377)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at 
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)



Default JAva version in this machcne is java6,  while start MS, we need to pick 
java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME

We need to fix this in classpath.conf


export CLASSPATH
if   [[ ! -d "$JAVA_HOME" && -d /usr/lib/jvm/jre-1.7.0 ]]; then
 export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
fi
PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH
export PATH 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7474:

Priority: Critical  (was: Major)

> Failed to start MS with java7 version mismatch error
> 
>
> Key: CLOUDSTACK-7474
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps  to reproduce 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> Result 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start with below error 
> SEVERE: Null component 
> Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
> Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory
> SEVERE: Error deploying web application directory client
> java.lang.UnsupportedClassVersionError: 
> org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : 
> Unsupported major.minor version 51.0 (unable to load class 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
> at 
> org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
> at 
> org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
> at 
> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074)
> at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4377)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
> Default JAva version in this machcne is java6,  while start MS, we need to 
> pick java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME
> We need to fix this in classpath.conf
> export CLASSPATH
> if   [[ ! -d "$JAVA_HOME" && -d /usr/lib/jvm/jre-1.7.0 ]]; then
>  export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
> fi
> PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH
> export PATH 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7473:
--

 Summary: [LXC]putting host into maintenance is failing 
 Key: CLOUDSTACK-7473
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Blocker


Repro stesp:
1. create a zone with a LXC cluster having 2 host
2. create few LXC vms
3. Put one host into maintenance which has some VM  running


Bug:
Putting host into maintenance will never pass. host will remain in preparing 
for maintenance stage and then goes to disconnect state.


Agent log shows :
2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-1:null) Failed to execute while migrating domain: 
org.libvirt.LibvirtException: this function is not supported by the connection 
driver: virDomainMigrate2
2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Seq 1-3693233169420517550:  { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1, 
Flags: 10, 
[{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
 this function is not supported by the connection driver: 
virDomainMigrate2","wait":0}}] }
2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null) 
Request:Seq 1-3693233169420517551:  { Cmd , MgmtId: 233845178472723, via: 1, 
Ver: v1, Flags: 100011, 
[{"com.cloud.agent.api.MigrateCommand":{"vmName":"i-2-7-VM","destIp":"10.147.28.49","hostGuid":"2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource","isWindows":false,"vmTO":{"id":7,"name":"i-2-7-VM","type":"User","cpus":1,"minSpeed":128,"maxSpeed":128,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Red
 Hat Enterprise Linux 
7.0","platformEmulator":"Other","bootArgs":"","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"QY0cKnTfogzaS49R283f1g==","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"caf07a92-9f6c-49df-a7e4-27289e715448","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"981fe152-6ee5--ae41-474736c881cf","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-7","size":647321600,"path":"981fe152-6ee5--ae41-474736c881cf","volumeId":7,"vmName":"i-2-7-VM","accountId":2,"format":"DIR","provisioningType":"THIN","id":7,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"981fe152-6ee5--ae41-474736c881cf","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"647321600"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"95826449-4163-46b8-91b7-8bf94f19ab8e","uuid":"d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f","ip":"10.147.30.166","netmask":"255.255.255.0","gateway":"10.147.30.1","mac":"06:54:96:00:00:07","dns1":"10.140.50.6","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://30","isolationUri":"vlan://30","isSecurityGroupEnabled":true}]},"executeInSequence":false,"wait":0}}]
 }
2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null) 
Processing command: com.cloud.agent.api.MigrateCommand
2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection] 
(agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM, 
continue
2014-09-02 19:08:13,018 INFO  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
2014-09-02 19:08:13,103 INFO  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete, 
waited 1000ms
2014-09-02 19:08:13,118 INFO  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-4:null) Failed to execute while migrating domain: 
org.libvirt.LibvirtException: this function is not supported by the connection 
driver: virDomainMigrate2
2014-09-02 19:08:13,124 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null) 
Seq 1-3693233169420517551:  { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1, 
Flags: 10, 
[{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
 this funct

[jira] [Created] (CLOUDSTACK-7472) [LXC] change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7472:
--

 Summary: [LXC] change cloudstack agent.properties file for rhel 7 
to include kvmclock.disable=true
 Key: CLOUDSTACK-7472
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0



We need to minimize manual steps that needs to be done after agent installation 
so change cloudstack agent.properties file for rhel 7 to include 
kvmclock.disable=true






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7461) [LXC] router VM not coming up in SG enabled Advance zone

[shweta agarwal (JIRA)]

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

shweta agarwal closed CLOUDSTACK-7461.
--
Resolution: Fixed

not valid

> [LXC] router VM not coming up in SG enabled Advance zone
> 
>
> Key: CLOUDSTACK-7461
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7461
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: agent-lxc.tar.gz, agent.log.tar.gz, 
> management-server.log.tar.gz
>
>
> Repro steps:
> Create a SG enables Advance zone with two clusters (one KVM and one LXC)
> Try creating VM in it
> Bug:
> VM  creation will fail because router is not coming up because Unable to 
> start VM on Host[-5-Routing] due to unsupported configuration: timer kvmclock 
> doesn't support setting of timer tickpolicy
> Ms log shows :
> 2014-09-01 14:45:56,464 DEBUG [c.c.a.t.Request] (AgentManager-Handler-8:null) 
> Seq 5-6836464234348412956: Processing:  { Ans: , MgmtId: 233845178472948, 
> via: 5, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":4,"name":"r-4-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Debian
>  GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":" 
> template=domP name=r-4-VM eth0ip=10.147.30.163 eth0mask=255.255.255.0 
> gateway=10.147.30.1 domain=cs1cloud.internal cidrsize=24 
> dhcprange=10.147.30.1 eth1ip=169.254.3.219 eth1mask=255.255.0.0 type=dhcpsrvr 
> disable_rp_filter=true 
> dns1=10.140.50.6","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"mRt576EtrOJFYfW6crRSHw==","vncAddr":"10.147.28.49","params":{},"uuid":"34aac78f-dc67-41b7-b91c-11440b6bedfd","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"244c8949-130f-4e23-afe9-2e4f596d9621","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-4","size":262144,"path":"244c8949-130f-4e23-afe9-2e4f596d9621","volumeId":4,"vmName":"r-4-VM","accountId":1,"format":"QCOW2","provisioningType":"THIN","id":4,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"244c8949-130f-4e23-afe9-2e4f596d9621","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"262144"}}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":true,"nicUuid":"6eec6504-df1d-49c3-a262-282752aae789","uuid":"0a5a9827-57d3-413b-8816-a81d1208c891","ip":"10.147.30.163","netmask":"255.255.255.0","gateway":"10.147.30.1","mac":"06:21:68:00:00:04","dns1":"10.140.50.6","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://30","isolationUri":"vlan://30","isSecurityGroupEnabled":true},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"pxeDisable":true,"nicUuid":"8dbb8ccf-a3bf-441b-8c9b-952166a38544","uuid":"54a9b8c0-f895-44a4-8517-fabdaaee1040","ip":"169.254.3.219","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:03:db","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"result":false,"details":"unsupported
>  configuration: timer kvmclock doesn't support setting of timer 
> tickpolicy","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous 
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous 
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous 
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous 
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous 
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
>  by previous failure","wait":0}}] }
> 2014-09-01 14:45:56,464 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-1:ctx-4bf54ed2 job-38/job-39 ctx-120a90f6) Seq 
> 5-6836464234348412956: Received:  { Ans: , MgmtId: 233845178472948, via: 5, 
> Ver: v1, Flags: 10, { StartAnswer, Answer, Answer, Answer, Answer, Answer, 
> Answer } }
> 2014-09-01 14:45:56,482 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-1:ctx-4bf54ed2 job-38/job-39 ctx-120a9

[jira] [Resolved] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.

[Min Chen (JIRA)]

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

Min Chen resolved CLOUDSTACK-7471.
--
Resolution: Fixed

> Regular user is allowed to deleteNetwork/RestartNetwork that does not belong 
> to him.He is also able to deploy Vm for other users.
> -
>
> Key: CLOUDSTACK-7471
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Min Chen
>
> Scenario 1 :
> Regular user is allowed to delete networks that belong to other users
> Create a regular user - d1-a in Domain - d1.
> Create another regular user - d1-b in Domain - d1.
> As user d1-a , create a network.
> As user d1-b , delete network that belongs to d1-a.
> We expect this to not succeed.
> But we are allowed to do this.
> Snippet from apilog indicating AccountId- 92 is attempting the restart 
> network.
> 2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) (userId=92 accountId=92 
> sessionId=DC
> A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET 
> command=deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessi
> onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { "deletenetworkresponse" :
> {"jobid":"05daf212-1aa7-4885-b133-2645a6ceb7df"}
> }
> Snippet from DB indicating that the owner of network is account_id=89 .
> mysql> select account_id,domain_id from networks where 
> uuid="2f2cc737-ba0f-4806-a81b-92a5749cfe7b";
> -+
> account_iddomain_id
> -+
> 8937
> -+
> 1 row in set (0.00 sec)
> Snippet from management server logs indicating success:
> 2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
> details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None, 
> instanceId: null, cmd: org.apache.cloudstack.api.comman
> d.user.network.DeleteNetworkCmd, cmdInfo: 
> {"response":"json","id":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","sessionkey":"NHvM0k5Rg/Qs
> pJg2g0YnQP/hq34\u003d","ctxDetails":"
> {\"com.cloud.network.Network\":\"2f2cc737-ba0f-4806-a81b-92a5749cfe7b\"}
> ","cmdEventType":"NETW
> ORK.DELETE","ctxUserId":"92","httpmethod":"GET","uuid":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","ctxAccountId":"92","ctxStartEventId"
> :"3020"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 
> 0, result: null, initMsid: 82324189320212, completeMsid
> : null, lastUpdated: null, lastPolled: null, created: null}
> 2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) ===END=== 10.215.3.6 – GET 
> command
> =deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
> 2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
> ready shutdown: Ntwk[390|Guest|8]
> 2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
> orwarding rules for network id=390
> 2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
> nat rules for network id=390
> 2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
> forwarding rules to apply for network id=390
> 2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
> c nat rules to apply for network id=390
> 2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
> sed rules for network id=390 and # of rules now = 0
> 2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
> cleaned up portForwarding/staticNat rules for network id=390
> 2014-08-29 06:59:57,942 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Found
> 0 lb rules to cleanup
> 2014-08-29 06:59:57,942 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
> cleaned up load balancing rules for network id=390
> 2014-08-29 06:59:57,949 DEBUG [c.c.n.f.FirewallManagerImpl] 
> (API-Job-Executor-40:ctx-710

[jira] [Commented] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.

[Min Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119337#comment-14119337
 ] 

Min Chen commented on CLOUDSTACK-7471:
--

This bug is caused by incorrect merge resolution in cherry-picking the commit 
of disabling IAM feature from 4.4 to master branch.
Sangeetha has written marvin automated testcases for these bugs, can simply 
verify the fix by running those automated tests.


> Regular user is allowed to deleteNetwork/RestartNetwork that does not belong 
> to him.He is also able to deploy Vm for other users.
> -
>
> Key: CLOUDSTACK-7471
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Min Chen
>
> Scenario 1 :
> Regular user is allowed to delete networks that belong to other users
> Create a regular user - d1-a in Domain - d1.
> Create another regular user - d1-b in Domain - d1.
> As user d1-a , create a network.
> As user d1-b , delete network that belongs to d1-a.
> We expect this to not succeed.
> But we are allowed to do this.
> Snippet from apilog indicating AccountId- 92 is attempting the restart 
> network.
> 2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) (userId=92 accountId=92 
> sessionId=DC
> A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET 
> command=deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessi
> onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { "deletenetworkresponse" :
> {"jobid":"05daf212-1aa7-4885-b133-2645a6ceb7df"}
> }
> Snippet from DB indicating that the owner of network is account_id=89 .
> mysql> select account_id,domain_id from networks where 
> uuid="2f2cc737-ba0f-4806-a81b-92a5749cfe7b";
> -+
> account_iddomain_id
> -+
> 8937
> -+
> 1 row in set (0.00 sec)
> Snippet from management server logs indicating success:
> 2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
> details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None, 
> instanceId: null, cmd: org.apache.cloudstack.api.comman
> d.user.network.DeleteNetworkCmd, cmdInfo: 
> {"response":"json","id":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","sessionkey":"NHvM0k5Rg/Qs
> pJg2g0YnQP/hq34\u003d","ctxDetails":"
> {\"com.cloud.network.Network\":\"2f2cc737-ba0f-4806-a81b-92a5749cfe7b\"}
> ","cmdEventType":"NETW
> ORK.DELETE","ctxUserId":"92","httpmethod":"GET","uuid":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","ctxAccountId":"92","ctxStartEventId"
> :"3020"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 
> 0, result: null, initMsid: 82324189320212, completeMsid
> : null, lastUpdated: null, lastPolled: null, created: null}
> 2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) ===END=== 10.215.3.6 – GET 
> command
> =deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
> 2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
> ready shutdown: Ntwk[390|Guest|8]
> 2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
> orwarding rules for network id=390
> 2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
> nat rules for network id=390
> 2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
> forwarding rules to apply for network id=390
> 2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
> c nat rules to apply for network id=390
> 2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
> sed rules for network id=390 and # of rules now = 0
> 2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
> cleaned up portForwarding/staticNat rules for network id=390
> 2014-08-29 06:59:57,942 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Found
> 0 lb rules t

[jira] [Commented] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119088#comment-14119088
 ] 

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

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

CLOUDSTACK-7471:Regular user is allowed to deleteNetwork/RestartNetwork
that does not belong to him.He is also able to deploy Vm for other
users.


> Regular user is allowed to deleteNetwork/RestartNetwork that does not belong 
> to him.He is also able to deploy Vm for other users.
> -
>
> Key: CLOUDSTACK-7471
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Min Chen
>
> Scenario 1 :
> Regular user is allowed to delete networks that belong to other users
> Create a regular user - d1-a in Domain - d1.
> Create another regular user - d1-b in Domain - d1.
> As user d1-a , create a network.
> As user d1-b , delete network that belongs to d1-a.
> We expect this to not succeed.
> But we are allowed to do this.
> Snippet from apilog indicating AccountId- 92 is attempting the restart 
> network.
> 2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) (userId=92 accountId=92 
> sessionId=DC
> A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET 
> command=deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessi
> onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { "deletenetworkresponse" :
> {"jobid":"05daf212-1aa7-4885-b133-2645a6ceb7df"}
> }
> Snippet from DB indicating that the owner of network is account_id=89 .
> mysql> select account_id,domain_id from networks where 
> uuid="2f2cc737-ba0f-4806-a81b-92a5749cfe7b";
> -+
> account_iddomain_id
> -+
> 8937
> -+
> 1 row in set (0.00 sec)
> Snippet from management server logs indicating success:
> 2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
> details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None, 
> instanceId: null, cmd: org.apache.cloudstack.api.comman
> d.user.network.DeleteNetworkCmd, cmdInfo: 
> {"response":"json","id":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","sessionkey":"NHvM0k5Rg/Qs
> pJg2g0YnQP/hq34\u003d","ctxDetails":"
> {\"com.cloud.network.Network\":\"2f2cc737-ba0f-4806-a81b-92a5749cfe7b\"}
> ","cmdEventType":"NETW
> ORK.DELETE","ctxUserId":"92","httpmethod":"GET","uuid":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","ctxAccountId":"92","ctxStartEventId"
> :"3020"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 
> 0, result: null, initMsid: 82324189320212, completeMsid
> : null, lastUpdated: null, lastPolled: null, created: null}
> 2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-23:ctx-05f928b8 ctx-c081eb69) ===END=== 10.215.3.6 – GET 
> command
> =deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
> 2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
> ready shutdown: Ntwk[390|Guest|8]
> 2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
> orwarding rules for network id=390
> 2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
> nat rules for network id=390
> 2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
> forwarding rules to apply for network id=390
> 2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
> c nat rules to apply for network id=390
> 2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
> sed rules for network id=390 and # of rules now = 0
> 2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
> cleaned up portForwarding/staticNat rules for network id=390
> 2014-08-29 06:59:57,942 DEBUG [c.c

[jira] [Created] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.

[Sangeetha Hariharan (JIRA)]

Sangeetha Hariharan created CLOUDSTACK-7471:
---

 Summary: Regular user is allowed to deleteNetwork/RestartNetwork 
that does not belong to him.He is also able to deploy Vm for other users.
 Key: CLOUDSTACK-7471
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
 Environment: build from master
Reporter: Sangeetha Hariharan
Assignee: Min Chen


Scenario 1 :
Regular user is allowed to delete networks that belong to other users

Create a regular user - d1-a in Domain - d1.
Create another regular user - d1-b in Domain - d1.
As user d1-a , create a network.
As user d1-b , delete network that belongs to d1-a.
We expect this to not succeed.
But we are allowed to do this.

Snippet from apilog indicating AccountId- 92 is attempting the restart network.
2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer] (catalina-exec-23:ctx-05f928b8 
ctx-c081eb69) (userId=92 accountId=92 sessionId=DC
A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET 
command=deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessi
onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { "deletenetworkresponse" :
{"jobid":"05daf212-1aa7-4885-b133-2645a6ceb7df"}

}

Snippet from DB indicating that the owner of network is account_id=89 .
mysql> select account_id,domain_id from networks where 
uuid="2f2cc737-ba0f-4806-a81b-92a5749cfe7b";
-+
account_id  domain_id

-+
89  37

-+
1 row in set (0.00 sec)

Snippet from management server logs indicating success:

2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None, 
instanceId: null, cmd: org.apache.cloudstack.api.comman
d.user.network.DeleteNetworkCmd, cmdInfo: 
{"response":"json","id":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","sessionkey":"NHvM0k5Rg/Qs
pJg2g0YnQP/hq34\u003d","ctxDetails":"
{\"com.cloud.network.Network\":\"2f2cc737-ba0f-4806-a81b-92a5749cfe7b\"}

","cmdEventType":"NETW
ORK.DELETE","ctxUserId":"92","httpmethod":"GET","uuid":"2f2cc737-ba0f-4806-a81b-92a5749cfe7b","ctxAccountId":"92","ctxStartEventId"
:"3020"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 82324189320212, completeMsid
: null, lastUpdated: null, lastPolled: null, created: null}
2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet] (catalina-exec-23:ctx-05f928b8 
ctx-c081eb69) ===END=== 10.215.3.6 – GET command
=deleteNetwork&id=2f2cc737-ba0f-4806-a81b-92a5749cfe7b&response=json&sessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
ready shutdown: Ntwk[390|Guest|8]
2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
orwarding rules for network id=390
2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
nat rules for network id=390
2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
forwarding rules to apply for network id=390
2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
c nat rules to apply for network id=390
2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
sed rules for network id=390 and # of rules now = 0
2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
cleaned up portForwarding/staticNat rules for network id=390
2014-08-29 06:59:57,942 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Found
0 lb rules to cleanup
2014-08-29 06:59:57,942 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
cleaned up load balancing rules for network id=390
2014-08-29 06:59:57,949 DEBUG [c.c.n.f.FirewallManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 firewall 
rules for network id=390
2014-08-29 06:59:57,950 DEBUG [c.c.n.f.FirewallManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no firewall 
rules to apply
2014-08-29 06:59:57,950 DEBUG [c.c.n.f.FirewallManagerImpl] 
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully released 
firewall rules for network id

[jira] [Assigned] (CLOUDSTACK-6694) [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic primary and secondary IPS.

[Brian Federle (JIRA)]

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

Brian Federle reassigned CLOUDSTACK-6694:
-

Assignee: (was: Brian Federle)

I implemented the front-end for this; needs to be assigned to someone to 
implement API calls.

I added a new property '_subselect' to the internal LB 'action' function, which 
contains the values for each respective dropdown. This can be used to add as 
additional properties to the assignToLoadBalancer call.

> [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic 
> primary and secondary IPS.
> ---
>
> Key: CLOUDSTACK-6694
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6694
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: InternalLB.jpg
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 48h
>
> 1. Create VPC.
> 2. Create a tier network using the network offering having internal LB 
> support.
> 3. Deploy VMs under this network.Acquire secondary Ips.
> 4.Goto VPC ->configure->tier-> internal LB.configure internal LB.
> 5. Assign VM to LB rule.
> Observation:
> There is no listing of primary and secondary IPs   for the VM while assigning 
> it  internal LB rule.
> attaching the screen shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6694) [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic primary and secondary IPS.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118731#comment-14118731
 ] 

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

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

CLOUDSTACK-6694: WIP: Add front-end for internal LB subselect


> [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic 
> primary and secondary IPS.
> ---
>
> Key: CLOUDSTACK-6694
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6694
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Assignee: Brian Federle
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: InternalLB.jpg
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 48h
>
> 1. Create VPC.
> 2. Create a tier network using the network offering having internal LB 
> support.
> 3. Deploy VMs under this network.Acquire secondary Ips.
> 4.Goto VPC ->configure->tier-> internal LB.configure internal LB.
> 5. Assign VM to LB rule.
> Observation:
> There is no listing of primary and secondary IPs   for the VM while assigning 
> it  internal LB rule.
> attaching the screen shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-5997) Template state changes side affects

[Nitin Mehta (JIRA)]

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

Nitin Mehta updated CLOUDSTACK-5997:

Fix Version/s: 4.4.0

> Template state changes side affects
> ---
>
> Key: CLOUDSTACK-5997
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
> Fix For: 4.4.0
>
>
> Template state change functionality.
> A state has been introduced for vm_template. It reflects the user action for 
> making template active/inactive for further use. 
> When the template is marked inactive it becomes unusable for the entire 
> cloud. 
> If the user wants to make it as inactive for a particular zone, 
> template_zone_ref would be accordingly reflected.
> Admin listing should still be able to see the inactive templates.
> The intent of the removed flag is to capture the system state meaning whether 
> it has been physically removed from the cloud. 
> The garbage collection thread checks the inactive state of the template and 
> deletes it physically from sec. storage when no vm is referencing this 
> template anymore. It also deletes it from PS.
> This is when the removed flag is set in the vm_template table. At the moment 
> this functionality doesn't exist in CS so the removed flag is never set as of 
> now.
> Things that need to be fixed
> Deleting the template by user for a particular zone should mark the removed 
> flag in template zone ref only. It should mark the template as inactive if 
> its there is no other zone carrying it.
> Deleting the template without any zone should mark it as inactive right away. 
> Removed flag is not set and there shouldn't be any code setting it at the 
> moment (Delete template shouldn't mark the removed flag.)
> Start showing the state in the api. Regular users should see only active 
> templates but admins should be able to see active/inactive templates
> Template Sync. Should start using active/inactive state than the removed flag.
> Show removed functionality introduced for CPBM would be fixed automatically 
> when admin sees the inactive state - 
> Any template code referencing the removed flag from vm_template should use 
> the active/inactive flag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-5997) Template state changes side affects

[Nitin Mehta (JIRA)]

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

Nitin Mehta updated CLOUDSTACK-5997:

Affects Version/s: 4.3.0

> Template state changes side affects
> ---
>
> Key: CLOUDSTACK-5997
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
> Fix For: 4.4.0
>
>
> Template state change functionality.
> A state has been introduced for vm_template. It reflects the user action for 
> making template active/inactive for further use. 
> When the template is marked inactive it becomes unusable for the entire 
> cloud. 
> If the user wants to make it as inactive for a particular zone, 
> template_zone_ref would be accordingly reflected.
> Admin listing should still be able to see the inactive templates.
> The intent of the removed flag is to capture the system state meaning whether 
> it has been physically removed from the cloud. 
> The garbage collection thread checks the inactive state of the template and 
> deletes it physically from sec. storage when no vm is referencing this 
> template anymore. It also deletes it from PS.
> This is when the removed flag is set in the vm_template table. At the moment 
> this functionality doesn't exist in CS so the removed flag is never set as of 
> now.
> Things that need to be fixed
> Deleting the template by user for a particular zone should mark the removed 
> flag in template zone ref only. It should mark the template as inactive if 
> its there is no other zone carrying it.
> Deleting the template without any zone should mark it as inactive right away. 
> Removed flag is not set and there shouldn't be any code setting it at the 
> moment (Delete template shouldn't mark the removed flag.)
> Start showing the state in the api. Regular users should see only active 
> templates but admins should be able to see active/inactive templates
> Template Sync. Should start using active/inactive state than the removed flag.
> Show removed functionality introduced for CPBM would be fixed automatically 
> when admin sees the inactive state - 
> Any template code referencing the removed flag from vm_template should use 
> the active/inactive flag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-5997) Template state changes side affects

[Nitin Mehta (JIRA)]

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

Nitin Mehta updated CLOUDSTACK-5997:

Description: 
Template state change functionality.
A state has been introduced for vm_template. It reflects the user action for 
making template active/inactive for further use. 
When the template is marked inactive it becomes unusable for the entire cloud. 
If the user wants to make it as inactive for a particular zone, 
template_zone_ref would be accordingly reflected.
Admin listing should still be able to see the inactive templates.
The intent of the removed flag is to capture the system state meaning whether 
it has been physically removed from the cloud. 
The garbage collection thread checks the inactive state of the template and 
deletes it physically from sec. storage when no vm is referencing this template 
anymore. It also deletes it from PS.
This is when the removed flag is set in the vm_template table. At the moment 
this functionality doesn't exist in CS so the removed flag is never set as of 
now.
Things that need to be fixed
Deleting the template by user for a particular zone should mark the removed 
flag in template zone ref only. It should mark the template as inactive if its 
there is no other zone carrying it.
Deleting the template without any zone should mark it as inactive right away. 
Removed flag is not set and there shouldn't be any code setting it at the 
moment (Delete template shouldn't mark the removed flag.)
Start showing the state in the api. Regular users should see only active 
templates but admins should be able to see active/inactive templates
Template Sync. Should start using active/inactive state than the removed flag.
Show removed functionality introduced for CPBM would be fixed automatically 
when admin sees the inactive state - 
Any template code referencing the removed flag from vm_template should use the 
active/inactive flag.

> Template state changes side affects
> ---
>
> Key: CLOUDSTACK-5997
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
>
> Template state change functionality.
> A state has been introduced for vm_template. It reflects the user action for 
> making template active/inactive for further use. 
> When the template is marked inactive it becomes unusable for the entire 
> cloud. 
> If the user wants to make it as inactive for a particular zone, 
> template_zone_ref would be accordingly reflected.
> Admin listing should still be able to see the inactive templates.
> The intent of the removed flag is to capture the system state meaning whether 
> it has been physically removed from the cloud. 
> The garbage collection thread checks the inactive state of the template and 
> deletes it physically from sec. storage when no vm is referencing this 
> template anymore. It also deletes it from PS.
> This is when the removed flag is set in the vm_template table. At the moment 
> this functionality doesn't exist in CS so the removed flag is never set as of 
> now.
> Things that need to be fixed
> Deleting the template by user for a particular zone should mark the removed 
> flag in template zone ref only. It should mark the template as inactive if 
> its there is no other zone carrying it.
> Deleting the template without any zone should mark it as inactive right away. 
> Removed flag is not set and there shouldn't be any code setting it at the 
> moment (Delete template shouldn't mark the removed flag.)
> Start showing the state in the api. Regular users should see only active 
> templates but admins should be able to see active/inactive templates
> Template Sync. Should start using active/inactive state than the removed flag.
> Show removed functionality introduced for CPBM would be fixed automatically 
> when admin sees the inactive state - 
> Any template code referencing the removed flag from vm_template should use 
> the active/inactive flag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

[Will Stevens (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118671#comment-14118671
 ] 

Will Stevens commented on CLOUDSTACK-7468:
--

I have pushed this fix as the 'hotfix/4.4-7468' to the repo: 
https://git-wip-us.apache.org/repos/asf/cloudstack.git

> NetScaler SSL Termination does not handle Projects as expected
> --
>
> Key: CLOUDSTACK-7468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0, 4.4.1
>Reporter: Will Stevens
>Assignee: Will Stevens
> Attachments: 
> CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch
>
>
> Currently the 'uploadSslCert' api call does not take any details about who 
> should own the SSL Cert.  It basically assigns the cert to the caller and 
> thats it.
> This breaks the expected behavior for projects and also does not allow for an 
> admin to upload certificates on behalf of one of their users.
> This fix should not adjust the database entities at all, but should allow the 
> API calls to handle the additional cases.
> The following changes should be made:
> - If 'uploadSslCert' is called without any account details, it should behave 
> how it does now and assign the cert to the caller.
> - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
> uploaded cert will be applied to that account.
> - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
> project.
> - The 'listSslCerts' api should also take an optional 'projectid' field to 
> list the ssl certs associated with that project.  
> - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
> updated to include additional information about the account or project as 
> well as the domain in which the cert is assigned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118667#comment-14118667
 ] 

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

Commit 92339bca0b0c8ecfc8b190e176dabfb0e8440f67 in cloudstack's branch 
refs/heads/hotfix/4.4-7468 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92339bc ]

CLOUDSTACK-7468: Fixed the NetScaler SSL Termination behavior with Projects


> NetScaler SSL Termination does not handle Projects as expected
> --
>
> Key: CLOUDSTACK-7468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0, 4.4.1
>Reporter: Will Stevens
>Assignee: Will Stevens
> Attachments: 
> CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch
>
>
> Currently the 'uploadSslCert' api call does not take any details about who 
> should own the SSL Cert.  It basically assigns the cert to the caller and 
> thats it.
> This breaks the expected behavior for projects and also does not allow for an 
> admin to upload certificates on behalf of one of their users.
> This fix should not adjust the database entities at all, but should allow the 
> API calls to handle the additional cases.
> The following changes should be made:
> - If 'uploadSslCert' is called without any account details, it should behave 
> how it does now and assign the cert to the caller.
> - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
> uploaded cert will be applied to that account.
> - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
> project.
> - The 'listSslCerts' api should also take an optional 'projectid' field to 
> list the ssl certs associated with that project.  
> - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
> updated to include additional information about the account or project as 
> well as the domain in which the cert is assigned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

[Will Stevens (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118639#comment-14118639
 ] 

Will Stevens commented on CLOUDSTACK-7468:
--

BTW, the attached patch is for the 4.4 branch and should be merged into the 
4.4.1 release.  I will put together a patch for master in a bit...

> NetScaler SSL Termination does not handle Projects as expected
> --
>
> Key: CLOUDSTACK-7468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0, 4.4.1
>Reporter: Will Stevens
>Assignee: Will Stevens
> Attachments: 
> CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch
>
>
> Currently the 'uploadSslCert' api call does not take any details about who 
> should own the SSL Cert.  It basically assigns the cert to the caller and 
> thats it.
> This breaks the expected behavior for projects and also does not allow for an 
> admin to upload certificates on behalf of one of their users.
> This fix should not adjust the database entities at all, but should allow the 
> API calls to handle the additional cases.
> The following changes should be made:
> - If 'uploadSslCert' is called without any account details, it should behave 
> how it does now and assign the cert to the caller.
> - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
> uploaded cert will be applied to that account.
> - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
> project.
> - The 'listSslCerts' api should also take an optional 'projectid' field to 
> list the ssl certs associated with that project.  
> - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
> updated to include additional information about the account or project as 
> well as the domain in which the cert is assigned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

[Will Stevens (JIRA)]

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

Will Stevens updated CLOUDSTACK-7468:
-
Attachment: 
CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch

For some reason I can not push a new 'hotfix/4.4-7468' branch right now, so 
here is a formatted patch for the 4.4 branch with the fix for this issue.

> NetScaler SSL Termination does not handle Projects as expected
> --
>
> Key: CLOUDSTACK-7468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0, 4.4.1
>Reporter: Will Stevens
>Assignee: Will Stevens
> Attachments: 
> CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch
>
>
> Currently the 'uploadSslCert' api call does not take any details about who 
> should own the SSL Cert.  It basically assigns the cert to the caller and 
> thats it.
> This breaks the expected behavior for projects and also does not allow for an 
> admin to upload certificates on behalf of one of their users.
> This fix should not adjust the database entities at all, but should allow the 
> API calls to handle the additional cases.
> The following changes should be made:
> - If 'uploadSslCert' is called without any account details, it should behave 
> how it does now and assign the cert to the caller.
> - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
> uploaded cert will be applied to that account.
> - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
> project.
> - The 'listSslCerts' api should also take an optional 'projectid' field to 
> list the ssl certs associated with that project.  
> - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
> updated to include additional information about the account or project as 
> well as the domain in which the cert is assigned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118536#comment-14118536
 ] 

Mike Tutkowski edited comment on CLOUDSTACK-7467 at 9/2/14 7:14 PM:


I went ahead and checked in the text changes.

Sure...I don't mind reviewing the Marvin code. I'll take a look at that now.


was (Author: mike-tutkowski):
I went ahead and checked in the text changes.

Sure...I don't mind reviewing the Marvin code. I'll take a look at that now.






-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*


> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7470) Use CSS for even-odd row display

[Brian Federle (JIRA)]

Brian Federle created CLOUDSTACK-7470:
-

 Summary: Use CSS for even-odd row display
 Key: CLOUDSTACK-7470
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7470
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Brian Federle
Priority: Minor


Currently, a custom JS function renders display of even odd list and form rows. 
This has turned out to be buggy in numerous situations, causing display issues 
and unnecessary code complexity when elements are variable. For example, when 
show-hiding fields in the zone wizard, often times the even-odd appearance 
doesn't show or are uneven.  A better solution is to render via CSS's 
'nth-child' selector, which will fix these issues, replacing the buggy 
'.evenOdd' function that is used now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118561#comment-14118561
 ] 

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

Commit 24dd6cee78ec779498b532d5dbb5015490642129 in cloudstack's branch 
refs/heads/master from [~alexbre]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24dd6ce ]

CLOUDSTACK-7467 Fix TestVolumes.test_07_resize_fail

Previously if you had a volume using a non customisable disk offering, and
attempted to resize it passing in the same disk offering id, the command would
be accepted, but it would actually be resized to its current size (i.e. the
provided size parameter was ignored). This is what the test used to check.

Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 modified the logic to check if
the provided diskofferingid was the same as the current one, and if so treat it
as if it hadn't been provided - this means the resize command now fails, which
is probably the more sensible thing to do (rather than giving the impression it
will be resized but actually not doing so).

This change therefore modifies the test logic to match.

Signed-off-by: Mike Tutkowski 


> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118536#comment-14118536
 ] 

Mike Tutkowski commented on CLOUDSTACK-7467:


I went ahead and checked in the text changes.

Sure...I don't mind reviewing the Marvin code. I'll take a look at that now.






-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*


> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118525#comment-14118525
 ] 

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

Commit ba41f230e19e66d108631d92e7c5f1d89083f81f in cloudstack's branch 
refs/heads/master from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ba41f23 ]

CLOUDSTACK-7467 (this part of the ticket is related to augmenting an error 
message)


> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Nitin Mehta (JIRA)]

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

Nitin Mehta reopened CLOUDSTACK-7316:
-

Reopening for my comment. I am fine with the fix though. 

> hitting java.lang.reflect.InvocationTargetException while starting usage 
> server
> ---
>
> Key: CLOUDSTACK-7316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: usage.tar.gz
>
>
> Repro steps:
> Install MS and usage server
> Start MS and usage server
> Bug:
> Usage server will stop after starting
> usage log shows :
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'vmDiskUsageParser': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
> at com.cloud.usage.UsageServer.start(UsageServer.java:57)
> ... 5 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
> autowire field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(Autowire

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

[Nitin Mehta (JIRA)]

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

Nitin Mehta commented on CLOUDSTACK-7316:
-

Damoder - Is this a recently introduced issue ? Can this be a problem for 
upgrade or say when customer thinks of starting usage server on the same 
machine ?

> hitting java.lang.reflect.InvocationTargetException while starting usage 
> server
> ---
>
> Key: CLOUDSTACK-7316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: usage.tar.gz
>
>
> Repro steps:
> Install MS and usage server
> Start MS and usage server
> Bug:
> Usage server will stop after starting
> usage log shows :
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'vmDiskUsageParser': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
> at com.cloud.usage.UsageServer.start(UsageServer.java:57)
> ... 5 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
> autowire field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInIni

[jira] [Created] (CLOUDSTACK-7469) Simulator build support need to extends for RPM build

[Rayees Namathponnan (JIRA)]

Rayees Namathponnan created CLOUDSTACK-7469:
---

 Summary: Simulator build support need to extends for RPM build  
 Key: CLOUDSTACK-7469
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7469
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
 Fix For: 4.5.0


Currently there is no option to build rpm with simulator, 

We need to update the package.sh file to accept simulator

cloud.spec file need to be updated  to build both oss and nooss simulator buids




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118423#comment-14118423
 ] 

Alex Brett commented on CLOUDSTACK-7467:


Review posted at https://reviews.apache.org/r/25258/ (if you're not happy 
reviewing the Marvin code let me know and I'll find someone here who can do so 
and then commit it for me).

Re: error message - your suggestion looks sensible to me, though I think it is 
probably quite a corner case so probably not a big deal either way!

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118362#comment-14118362
 ] 

Mike Tutkowski commented on CLOUDSTACK-7467:


True...if you have some text you'd like it changed to, let me know.

Could just be changed to something like this:

To change a volume's size without providing a new disk offering, its current 
disk offering must be customizable or it must be a root volume (if providing a 
disk offering, make sure it is different from the current disk offering).

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118360#comment-14118360
 ] 

Alex Brett commented on CLOUDSTACK-7467:


That's true - not sure how helpful it is though, as the user might not realise 
they've passed in the same disk offering ;)

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118359#comment-14118359
 ] 

Alex Brett commented on CLOUDSTACK-7467:


I'll prepare a patch that fixes up the test...

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118357#comment-14118357
 ] 

Mike Tutkowski commented on CLOUDSTACK-7467:


That's an interesting point about the content of the error message.

This is what it says:

"To change a volume's size without providing a new disk offering, its current 
disk offering must be customizable or it must be a root volume."

This text is technically correct, right? :) I mean, you didn't pass in a new 
disk offering, you passed in the current disk offering.

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118351#comment-14118351
 ] 

Alex Brett commented on CLOUDSTACK-7467:


bq. Can you tell me if my analysis is correct here (i.e. you used to not get an 
exception, but now you do)?

Correct - the test expects this resize to succeed, and it used to, but now it 
throws an exception.

bq. If so, I'm thinking the new logic is better than the old logic because it 
seems this test case was missing a problem (it was expecting the resize to work 
(i.e. not throw an exception), but in reality the code was ignoring the newly 
passed-in size and setting the size of the volume to be the same as it 
currently is).

That makes sense (though the error message in this case might want tweaking as 
it's quite misleading by claiming you didn't pass in a diskofferingid).

Looking at the test in more detail I can see the steps it executes are:
* Attempts to resize a volume with an invalid volume ID, verifies it gets an 
exception with "invalid" in it somewhere
* Attempts to resize a volume with an invalid disk offering ID, verifies it 
gets an exception with "invalid" in it somewhere
* Attempts to resize a root disk using a disk offering, verifies it gets an 
exception
* Attaches a volume that is not custom, then attempts to resize it (this is 
where it is now failing but wasn't previously), then verifies that the volume 
*doesn't* resize

So it looks like the test was actually verifying the behaviour as is, and all 
that needs modifying is for it to expect an exception rather than expecting the 
command to be accepted but not actually do the resize...

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118341#comment-14118341
 ] 

Mike Tutkowski edited comment on CLOUDSTACK-7467 at 9/2/14 4:53 PM:


Thanks for bringing this to my attention.

So, the change I put in was to examine the disk offering ID, if any, that is 
passed in (we'll call this the new disk offering ID). If the new disk offering 
ID is not null and it is the same disk offering ID as the current disk offering 
ID of the volume in question, then we "pretend" like you passed in null for the 
new disk offering ID (rather than having the current and new disk offering IDs 
be equal).

It seems that this part of the test is trying to change the size of a volume 
when the volume's disk offering ID is not customizable.

It looks like the old logic path would ignore the size that you passed into the 
API in favor of the fixed size of the "new" disk offering ID.

The new logic throws an exception, though.

Can you tell me if my analysis is correct here (i.e. you used to not get an 
exception, but now you do)?

If so, I'm thinking the new logic is better than the old logic because it seems 
this test case was missing a problem (it was expecting the resize to work (i.e. 
not throw an exception), but in reality the code was ignoring the newly 
passed-in size and setting the size of the volume to be the same as it 
currently is).


was (Author: mike-tutkowski):
Thanks for bringing this to my attention.

So, the change I put in was to examine the disk offering ID, if any, that is 
passed in (we'll call this the new disk offering ID). If the new disk offering 
ID is not null and it is the same disk offering ID as the current disk offering 
ID of the volume in question, then we "pretend" like you passed in null for the 
new disk offering ID (rather than having the current and new disk offering IDs 
be equal).

It seems that this part of the test is trying to change the size of a volume 
when the volume's disk offering ID is not customizable.

It looks like the old logic path would ignore the size that you passed into the 
API in favor of the fixed size of the "new" disk offering ID.

The new logic throws an exception, though.

Can you tell me if my analysis is correct here (i.e. you used to not get an 
exception, but now you do)?

If so, I'm thinking the new logic is better than the old logic because it seems 
this test case was missing a problem (it was expecting the resize to work (i.e. 
not throw an exception), but in reality the test was ignoring the newly 
passed-in size and setting the size of the volume to be the same as it 
currently is).

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured st

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118341#comment-14118341
 ] 

Mike Tutkowski commented on CLOUDSTACK-7467:


Thanks for bringing this to my attention.

So, the change I put in was to examine the disk offering ID, if any, that is 
passed in (we'll call this the new disk offering ID). If the new disk offering 
ID is not null and it is the same disk offering ID as the current disk offering 
ID of the volume in question, then we "pretend" like you passed in null for the 
new disk offering ID (rather than having the current and new disk offering IDs 
be equal).

It seems that this part of the test is trying to change the size of a volume 
when the volume's disk offering ID is not customizable.

It looks like the old logic path would ignore the size that you passed into the 
API in favor of the fixed size of the "new" disk offering ID.

The new logic throws an exception, though.

Can you tell me if my analysis is correct here (i.e. you used to not get an 
exception, but now you do)?

If so, I'm thinking the new logic is better than the old logic because it seems 
this test case was missing a problem (it was expecting the resize to work (i.e. 
not throw an exception), but in reality the test was ignoring the newly 
passed-in size and setting the size of the volume to be the same as it 
currently is).

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6756) usage id is not being returned for an ip in deleted ip range

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118338#comment-14118338
 ] 

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

Commit 79edd933b3dfae9e56a71b72902e876a9816389b in cloudstack's branch 
refs/heads/hotfix/4.3-CLOUDSTACK-6756 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=79edd93 ]

Fixed CLOUDSTACK-6756: usage id is not being returned for an ip in deleted ip 
range

(cherry picked from commit df42ce903d399cf30055e55bc24b84fbc0b563a9)
Signed-off-by: Rohit Yadav 

Conflicts:
api/src/com/cloud/network/IpAddress.java
engine/components-api/src/com/cloud/network/addr/PublicIp.java
engine/schema/src/com/cloud/dc/VlanVO.java
engine/schema/src/com/cloud/network/dao/IPAddressVO.java
server/src/com/cloud/configuration/ConfigurationManagerImpl.java

Deleted:
setup/db/db/schema-430to440.sql


> usage id is not being returned for an ip in deleted ip range
> 
>
> Key: CLOUDSTACK-6756
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Usage
>Affects Versions: 4.3.0, 4.4.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
>
> 1. acquire an ip in an ip range
> 2. after some usage is recorded, release the ip 
> 3. delete the ip range
> 4. call list usage records
> This doesn't return the usage id for the ip acquired in step 1. 
> the ip's are hard deleted from the ip range and hence the api service couldnt 
> get the uuid of the deleted ip.
> ip_addresses should be soft deleted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

[Will Stevens (JIRA)]

Will Stevens created CLOUDSTACK-7468:


 Summary: NetScaler SSL Termination does not handle Projects as 
expected
 Key: CLOUDSTACK-7468
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.5.0, 4.4.1
Reporter: Will Stevens
Assignee: Will Stevens


Currently the 'uploadSslCert' api call does not take any details about who 
should own the SSL Cert.  It basically assigns the cert to the caller and thats 
it.

This breaks the expected behavior for projects and also does not allow for an 
admin to upload certificates on behalf of one of their users.

This fix should not adjust the database entities at all, but should allow the 
API calls to handle the additional cases.

The following changes should be made:
- If 'uploadSslCert' is called without any account details, it should behave 
how it does now and assign the cert to the caller.
- If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
uploaded cert will be applied to that account.
- If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
project.
- The 'listSslCerts' api should also take an optional 'projectid' field to list 
the ssl certs associated with that project.  
- The api response for both 'uploadSslCert' and 'listSslCerts' should be 
updated to include additional information about the account or project as well 
as the domain in which the cert is assigned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted

[Rohit Yadav (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118218#comment-14118218
 ] 

Rohit Yadav commented on CLOUDSTACK-6945:
-

This is the corner case when the template has been removed and ACS throws NPE 
as template is null. The fix would be to check template and if it's null we 
throw resource not available exception;
https://reviews.apache.org/r/25248/

I was not sure what else could break, so submitted it as a review

> Null pointer exception when starting a VM that had its template deleted
> ---
>
> Key: CLOUDSTACK-6945
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
> Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud 
> Platform packages installed and properly configured.
>Reporter: Rafael Weingartner
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.3.1
>
>
> It seems that you have a bug in CS 4.3.0(and probably previous versions?) 
> when starting a machine that was created from a template that has been 
> deleted.
> There will happen a null pointer exception in 
> "com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart":
> “858 -if (volTemplateId != null && volTemplateId.longValue() != 
> template.getId())”
> The object, “template” is going to be null, because in:
> “811 -  VirtualMachineTemplate template = 
> _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());”
> The findById, will add a where clause, looking for template that have the 
> column removed that is null, therefore It will return a null object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-6945:

Priority: Minor  (was: Blocker)

> Null pointer exception when starting a VM that had its template deleted
> ---
>
> Key: CLOUDSTACK-6945
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
> Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud 
> Platform packages installed and properly configured.
>Reporter: Rafael Weingartner
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.3.1
>
>
> It seems that you have a bug in CS 4.3.0(and probably previous versions?) 
> when starting a machine that was created from a template that has been 
> deleted.
> There will happen a null pointer exception in 
> "com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart":
> “858 -if (volTemplateId != null && volTemplateId.longValue() != 
> template.getId())”
> The object, “template” is going to be null, because in:
> “811 -  VirtualMachineTemplate template = 
> _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());”
> The findById, will add a where clause, looking for template that have the 
> column removed that is null, therefore It will return a null object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7466) VR can't assign IP to interface ethnull

[Vadim Kim. (JIRA)]

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

Vadim Kim. updated CLOUDSTACK-7466:
---
Description: 
While creating VPC new VR is created. Initially it should assign 2 IP: 
link-local to eth0 and public to eth1. 
Link-local is created and assigned successfully. 
Public can't be assigned, because system is looking for interface with name 
"ethnull"
Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 14 seconds 
Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 15 seconds 
Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 16 seconds 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
10.65.9.102 on interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
interface eth2


  was:
While creating VPC new VR is created. Initially it should assign 2 IP: 
link-local to eth0 and public to eth1. 
Link-local is created and assigned successfully. 
Public can't be assigned, because system is looking for interface with name 
"ethnull"
Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
 ethnull to appear, 14 seconds 
Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 15 seconds 
Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 16 seconds 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
10.65.9.102 on interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
interface eth2



> VR can't assign IP to interface ethnull
> ---
>
> Key: CLOUDSTACK-7466
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7466
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.0
>Reporter: Vadim Kim.
>
> While creating VPC new VR is created. Initially it should assign 2 IP: 
> link-local to eth0 and public to eth1. 
> Link-local is created and assigned successfully. 
> Public can't be assigned, because system is looking for interface with name 
> "ethnull"
> Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 14 seconds 
> Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 15 seconds 
> Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 16 seconds 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never 
> appeared 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
> 10.65.9.102 on interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
> interface eth2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7463) UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)

[Gabor Apati-Nagy (JIRA)]

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

Gabor Apati-Nagy resolved CLOUDSTACK-7463.
--
Resolution: Fixed

> UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)
> ---
>
> Key: CLOUDSTACK-7463
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7463
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Gabor Apati-Nagy
>Assignee: Gabor Apati-Nagy
> Fix For: 4.5.0
>
>
> Domain Admin UI shows the 'add ldap users' button. Trying to add LDAP users 
> will show an empty screen (even if LDAP is configured) and an error will be 
> displayed "the given command does not exist or it is not available for user".
> This makes sense as Domain Admin cannot use the importLdapUsers API call, 
> only ROOT Admin.
> The button should be removed for Domain Admins
> Steps to reproduce:
> 1) create LDAP integration
> 2) access as Domain Admin User of a sub-Domain
> 3) note the 'Add LDAP users' button
> 4) Try to add an LDAP user and note the error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

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

Alex Brett updated CLOUDSTACK-7467:
---
Attachment: runinfo.txt
management-server.log

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

Alex Brett created CLOUDSTACK-7467:
--

 Summary: TestVolumes.test_07_resize_fail failing
 Key: CLOUDSTACK-7467
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
 Fix For: 4.5.0
 Attachments: management-server.log, runinfo.txt

Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
 has caused the BVT test 
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start failing 
with:

{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
  File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, in 
test_07_resize_fail
self.apiClient.resizeVolume(cmd)
  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response, 
method=method)
  File "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", 
line 379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created : 
u'2014-09-02T12:19:32+', cmd : 
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
size without providing a new disk offering, its current disk offering must be 
customizable or it must be a root volume."}, accountid : 
u'71a306cc-3296-11e4-b130-0a474b082b17'}
 >> begin captured stdout << -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}

>From what I can see here the test is providing a diskofferingid in its 
>command, so the error text doesn't appear to make sense, but I'm not hugely 
>familiar with this area so it is possible the test has always been doing 
>something wrong...

I'll attach the full runinfo.txt and management server log from a run to this 
ticket - assigning initially to Mike Tutkowski as the author of the above 
commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7270) Deleting public IP range or guest network permanently removes DB row/entry

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-7270.
---

Duplicate

> Deleting public IP range or guest network permanently removes DB row/entry
> --
>
> Key: CLOUDSTACK-7270
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7270
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Usage
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1
>Reporter: Rohit Yadav
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
>
> If you remove a public IP range or a shared network, the entry from 
> user_ip_address gets removed but entry in cloud_usage.cloud_usage for the 
> type=3 (ip address) does not. In case of portable IPs we definetely remove IP 
> entries, for others we need to check. This was discovered in 4.2.1, and then 
> again in 4.3 release
> This logic causes NPE when listing usage records in the service layer when we 
> do IPAddressVO object.getUuid().
> We need to discuss why we are not marking them as removed and should we 
> remove entry from cloud_usage table for type=3 (ip address) since in 
> cloud_usage table there is no field that says marked as removed (its 
> reference in user_ip_address table etc.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6531) VR starts even if PF rules fails

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118146#comment-14118146
 ] 

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

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

CLOUDSTACK-6531: stopping the router in case of command failures. Also added 
alerts for failures.

Signed-off-by: Jayapal 
(cherry picked from commit 59bf3559196a9452a1a048849f4f9971753d373b)
Signed-off-by: Rohit Yadav 

Conflicts:

server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java


> VR starts even if PF rules fails
> 
>
> Key: CLOUDSTACK-6531
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6531
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.3.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.3.1
>
>
> If any of the PF rules or other commands fails during start, the router 
> ignores those and continues to start. The VR is in started state but, the 
> actual state of the router or the partial failures are hidden and there is no 
> way for an admin to know about them unless he checks logs.
> It would be good to stop the router and alert admin incase of failures as 
> there is no way to retry and we dont have any intermediate state for VR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7087) [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX client

[Harikrishna Patnala (JIRA)]

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

Harikrishna Patnala resolved CLOUDSTACK-7087.
-
   Resolution: Fixed
Fix Version/s: (was: 4.2.1)
   4.4.0

> [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX 
> client
> 
>
> Key: CLOUDSTACK-7087
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7087
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.0, 4.3.0
>Reporter: Sheng Yang
>Assignee: Harikrishna Patnala
> Fix For: 4.4.0, 4.3.1
>
>
> Latest OpenSwan fail to work with OSX/IOS after latest Debian security 
> update(Mar 2014, https://www.debian.org/security/2014/dsa-2893 ).
> And why Debian didn’t fix it officially, is because Debian decided to drop 
> the support for OpenSwan(since nobody is maintaining it and it hasn’t been 
> updated for 2 years before this security fix). We would need to move to other 
> VPN software in the future.
> Here is the Debian bugzilla for the issue. 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717
> So far, downgrade openswan is only an intermediate solution. We need to move 
> to other VPN software(e.g. StrongSwan) which is still maintained by Debain in 
> the near future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-6115) Investigate the use of TravisCI for CloudStack integration testing

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-6115.
---

Thanks to Ian we go this working. It's live for 4.3 and master branches;
https://travis-ci.org/apache/cloudstack

> Investigate the use of TravisCI for CloudStack integration testing
> --
>
> Key: CLOUDSTACK-6115
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6115
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sebastien goasguen
>Assignee: Ian Duffy
> Fix For: 4.5.0, 4.3.1
>
>
> Integration testing is currently performed using jenkins and the CloudStack 
> simulator.
> In this project the student will learn about integration testing and the 
> marvin framework in CloudStack (written in Python). The student will also 
> learn about TravisCI a system to perform continuous testing and integration 
> testing. 
> Using a github mirror, the student will setup Travis builds that will use the 
> cloudstack simulator and run the integration tests on each commit.
> This is a great project to learn about CI, tests and CloudStack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-6297) Cloudstack Fails to Launch on Ubuntu missing MySQL Driver

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-6297.
---

Fixed by 889d80b7e79ef55534727f088b2091e5b025d67c and 
f912bd7f23beee628f1963f58232eb970fb541f1

> Cloudstack Fails to Launch on Ubuntu missing MySQL Driver
> -
>
> Key: CLOUDSTACK-6297
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6297
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
> Environment: Ubuntu Server 13.10
>Reporter: Joshua Rogers
>Priority: Critical
> Fix For: 4.3.1
>
>
> On Ubuntu Server 13.10, installing Cloudstack 4.3 as specified in the 
> documentation does not produce a runnable system. Cloudstack-management dies 
> shortly after it starts with a stack trace indicating that it can't find the 
> MySQL driver (trace listed below.)
> This continues to occur after running
>apt-get install libmysql-java
>cp /usr/share/java/mysql-connector-java-5.1.25.jar 
> /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/
>reboot
> --- Stack Trace ---
> 2014-03-27 20:53:11,112 INFO  [c.c.u.d.T.Transaction] (main:null) Is Data 
> Base High Availiability enabled? Ans : false
> 2014-03-27 20:53:11,186 ERROR [c.c.u.d.Merovingian2] (main:null) Unable to 
> get a new db connection
> java.sql.SQLException: No suitable driver found for 
> jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true
> at java.sql.DriverManager.getConnection(DriverManager.java:635)
> at java.sql.DriverManager.getConnection(DriverManager.java:195)
> at 
> org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75)
> at 
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582)
> at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188)
> at 
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
> at 
> com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:204)
> at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68)
> at 
> com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:80)
> at 
> com.cloud.server.LockMasterListener.(LockMasterListener.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:534)
> at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148)
> at 
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121)
> at 
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:280)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1045)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:949)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at 
> org.apache.cloudstack.spr

[jira] [Assigned] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-6945:
---

Assignee: Rohit Yadav

> Null pointer exception when starting a VM that had its template deleted
> ---
>
> Key: CLOUDSTACK-6945
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
> Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud 
> Platform packages installed and properly configured.
>Reporter: Rafael Weingartner
>Assignee: Rohit Yadav
>Priority: Blocker
> Fix For: 4.3.1
>
>
> It seems that you have a bug in CS 4.3.0(and probably previous versions?) 
> when starting a machine that was created from a template that has been 
> deleted.
> There will happen a null pointer exception in 
> "com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart":
> “858 -if (volTemplateId != null && volTemplateId.longValue() != 
> template.getId())”
> The object, “template” is going to be null, because in:
> “811 -  VirtualMachineTemplate template = 
> _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());”
> The findById, will add a where clause, looking for template that have the 
> column removed that is null, therefore It will return a null object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7466) VR can't assign IP to interface ethnull

[Vadim Kim. (JIRA)]

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

Vadim Kim. updated CLOUDSTACK-7466:
---
Description: 
While creating VPC new VR is created. Initially it should assign 2 IP: 
link-local to eth0 and public to eth1. 
Link-local is created and assigned successfully. 
Public can't be assigned, because system is looking for interface with name 
"ethnull"
Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
 ethnull to appear, 14 seconds 
Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 15 seconds 
Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 16 seconds 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
10.65.9.102 on interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
interface eth2


  was:
Creating VPC new VR is created. Initially it should assign 2 IP: link-local to 
eth0 and public to eth1. 
Link-local is created and assigned successfully. 
Public can't be assigned, because system is looking for interface with name 
"ethnull"
Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
 ethnull to appear, 14 seconds 
Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 15 seconds 
Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 16 seconds 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
10.65.9.102 on interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
interface eth2



> VR can't assign IP to interface ethnull
> ---
>
> Key: CLOUDSTACK-7466
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7466
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.0
>Reporter: Vadim Kim.
>
> While creating VPC new VR is created. Initially it should assign 2 IP: 
> link-local to eth0 and public to eth1. 
> Link-local is created and assigned successfully. 
> Public can't be assigned, because system is looking for interface with name 
> "ethnull"
> Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
>  ethnull to appear, 14 seconds 
> Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 15 seconds 
> Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 16 seconds 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never 
> appeared 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
> 10.65.9.102 on interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
> interface eth2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7466) VR can't assign IP to interface ethnull

[Vadim Kim. (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118123#comment-14118123
 ] 

Vadim Kim. commented on CLOUDSTACK-7466:


Fresh logs from KVM host and management server:
http://pastebin.com/5hfLjuf0 -- security_group.log
http://pastebin.com/7rwAZ9Rc -- management-server.log

> VR can't assign IP to interface ethnull
> ---
>
> Key: CLOUDSTACK-7466
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7466
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.0
>Reporter: Vadim Kim.
>
> Creating VPC new VR is created. Initially it should assign 2 IP: link-local 
> to eth0 and public to eth1. 
> Link-local is created and assigned successfully. 
> Public can't be assigned, because system is looking for interface with name 
> "ethnull"
> Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
>  ethnull to appear, 14 seconds 
> Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 15 seconds 
> Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull 
> to appear, 16 seconds 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never 
> appeared 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
> interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
> 10.65.9.102 on interface ethnull 
> Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
> interface eth2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7466) VR can't assign IP to interface ethnull

[Vadim Kim. (JIRA)]

Vadim Kim. created CLOUDSTACK-7466:
--

 Summary: VR can't assign IP to interface ethnull
 Key: CLOUDSTACK-7466
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7466
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.4.0
Reporter: Vadim Kim.


Creating VPC new VR is created. Initially it should assign 2 IP: link-local to 
eth0 and public to eth1. 
Link-local is created and assigned successfully. 
Public can't be assigned, because system is looking for interface with name 
"ethnull"
Aug 15 08:49:29 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface
 ethnull to appear, 14 seconds 
Aug 15 08:49:30 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 15 seconds 
Aug 15 08:49:31 r-17-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to 
appear, 16 seconds 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Adding ip 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_ipassoc.sh:Add routing 10.65.9.102 on 
interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_privateGateway.sh:Added SourceNAT 
10.65.9.102 on interface ethnull 
Aug 15 08:49:32 r-17-VM cloud: vpc_snat.sh:Added SourceNAT 10.65.9.102 on 
interface eth2




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6927) Security group python script has several issues

[Rohit Yadav (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118120#comment-14118120
 ] 

Rohit Yadav commented on CLOUDSTACK-6927:
-

Looks like this was fixed, should we resolve it?

> Security group python script has several issues
> ---
>
> Key: CLOUDSTACK-6927
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6927
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.4.0, 4.3.1
>Reporter: sebastien goasguen
> Fix For: 4.3.1
>
>
> -virtual router is not cleaned up properly from iptables
> -routes are not cleaned up properly if needed
> -not using python list to store results of virsh list.
> -there can be duplicates in cleanup list
> -



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-7291:

Fix Version/s: (was: 4.3.1)
   4.5.0
   Future

> LXC: Mgmt server/agent keeps killing systemvms
> --
>
> Key: CLOUDSTACK-7291
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.3.1
>Reporter: Rohit Yadav
>Assignee: Kishan Kavala
> Fix For: Future, 4.5.0
>
>
> Followed installation and setup docs of 4.3, was unable to get LXC to work on 
> Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
> ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
> mgmt server complained that it was unable to contact agent on the systemvm 
> (ping), while the agent would gracefully shutdown the systemvm (by killing 
> them).
> Relevant log:
> 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
> (secstorage-1:ctx-fc57ef43) Could not find exception: 
> com.cloud.exception.OperationTimedoutException in error code list for 
> exceptions
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
> (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
> Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
> id = 1, name = bluebox1.bhaisaab.org]
> 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Scheduled 
> HAWork[12-CheckStop-2-Starting-Scheduled]
> 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
> vm
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
> unreachable: Host 1: Unable to start s-2-VM
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
> >---at 
> >com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
> ...
> ...
> ...
> Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
> to Host 1 timed out after 3600
> >---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
> > 
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
> >---... 24 more   
> > 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7087) [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX client

[Rohit Yadav (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118118#comment-14118118
 ] 

Rohit Yadav commented on CLOUDSTACK-7087:
-

If this is fixed already (as I see some commits), please resolve/close it?

> [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX 
> client
> 
>
> Key: CLOUDSTACK-7087
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7087
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.0, 4.3.0
>Reporter: Sheng Yang
>Assignee: Harikrishna Patnala
> Fix For: 4.2.1, 4.3.1
>
>
> Latest OpenSwan fail to work with OSX/IOS after latest Debian security 
> update(Mar 2014, https://www.debian.org/security/2014/dsa-2893 ).
> And why Debian didn’t fix it officially, is because Debian decided to drop 
> the support for OpenSwan(since nobody is maintaining it and it hasn’t been 
> updated for 2 years before this security fix). We would need to move to other 
> VPN software in the future.
> Here is the Debian bugzilla for the issue. 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717
> So far, downgrade openswan is only an intermediate solution. We need to move 
> to other VPN software(e.g. StrongSwan) which is still maintained by Debain in 
> the near future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?

[Alex Brett (JIRA)]

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

Alex Brett resolved CLOUDSTACK-7455.

Resolution: Fixed

Resolving as this was fixed by the commit mentioned above...

> Unable to connect to management server ?since SAML2 merge?
> --
>
> Key: CLOUDSTACK-7455
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: management-server.log
>
>
> In builds that have the SAML2 merge in, while I can start the management 
> server, it appears not to fully startup, and doesn't give the UI or API.
> management-server.log (attached) stops at:
> {noformat}
> 2014-08-29 14:55:02,097 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
> (main:null) Starting CloudStack Components
> 2014-08-29 14:55:02,098 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
> (main:null) Done Starting CloudStack Components
> 2014-08-29 14:55:02,098 INFO  [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] 
> (main:null) Starting module [core]
> 2014-08-29 14:55:02,098 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
> (main:null) Starting CloudStack Components
> 2014-08-29 14:55:02,106 INFO  [c.c.h.h.m.HypervManagerImpl] (main:null) 
> Cleanup mounted mount points used in previous session
> 2014-08-29 14:55:02,141 INFO  [c.c.u.DatabaseIntegrityChecker] (main:null) 
> Grabbing lock to check for database integrity.
> 2014-08-29 14:55:02,143 INFO  [c.c.u.DatabaseIntegrityChecker] (main:null) 
> Performing database integrity check
> 2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No 
> duplicate hosts with the same local storage found in database
> 2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking 
> to see if the database is at a version before it was the version table is 
> created
> 2014-08-29 14:55:02,150 INFO  [c.c.c.ClusterManagerImpl] (main:null) Starting 
> Cluster manager, msid : 99326614648649
> 2014-08-29 14:55:02,155 INFO  [c.c.c.ClusterManagerImpl] (main:null) 
> Management server 99326614648649, runId 1409324073632 is being started
> 2014-08-29 14:55:02,156 INFO  [c.c.c.ClusterManagerImpl] (main:null) 
> Management server (host id : 1) is being started at 127.0.0.1:9090
> 2014-08-29 14:55:02,162 INFO  [c.c.c.ClusterManagerImpl] (main:null) Cluster 
> manager was started successfully
> 2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing: 
> /bin/bash -c /sbin/route | grep default 
> 2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is 
> successful.
> 2014-08-29 14:55:02,185 WARN  [c.c.c.ConfigurationManagerImpl] (main:null) 
> Management network CIDR is not configured originally. Set it default to 
> 10.220.128.0/19
> 2014-08-29 14:55:02,190 WARN  [o.a.c.alerts] (main:null)  alertType:: 14 // 
> dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management 
> network CIDR is not configured originally. Set it default to 10.220.128.0/19
> 2014-08-29 14:55:02,215 INFO  [c.c.h.HighAvailabilityManagerImpl] 
> (HA-Worker-0:null) Starting work
> 2014-08-29 14:55:02,224 INFO  [c.c.h.HighAvailabilityManagerImpl] 
> (HA-Worker-3:null) Starting work
> 2014-08-29 14:55:02,224 INFO  [c.c.h.HighAvailabilityManagerImpl] 
> (HA-Worker-4:null) Starting work
> 2014-08-29 14:55:02,218 INFO  [c.c.h.HighAvailabilityManagerImpl] 
> (HA-Worker-2:null) Starting work
> 2014-08-29 14:55:02,218 INFO  [c.c.h.HighAvailabilityManagerImpl] 
> (HA-Worker-1:null) Starting work
> 2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null) 
> LB HealthCheckmanager is getting Started
> 2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network 
> stats
> 2014-08-29 14:55:11,061 INFO  [c.c.u.c.ComponentContext] (main:null) 
> Configuring 
> com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
> 2014-08-29 14:55:11,066 INFO  [c.c.u.c.ComponentContext] (main:null) 
> Configuring 
> com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
> 2014-08-29 14:55:11,066 INFO  [c.c.u.c.ComponentContext] (main:null) 
> Configuring 
> com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
> 2014-08-29 14:55:11,066 INFO  [c.c.u.c.ComponentContext] (main:null) 
> Configuring 
> com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_ae893256
> 2014-08-29 14:55:11,067 INFO  [c.c.u.c.ComponentContext] (main:null) 
> Configuring 
> com.cloud.bridge.persist.dao.UserCredentia

[jira] [Updated] (CLOUDSTACK-7460) [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine

[Damodar Reddy T (JIRA)]

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

Damodar Reddy T updated CLOUDSTACK-7460:

Priority: Major  (was: Critical)

> [LXC][RHEl7] Agent installaion fails if Management server is already 
> installed on the same machine
> --
>
> Key: CLOUDSTACK-7460
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7460
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup, KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
> Fix For: 4.5.0
>
>
> Repro steps:
> on rhel 7 Machine. First install MS and try installing Agent on the same 
> machine
> Bug:
> Agent installation will fail with following error :
> Transaction check error:
>   file /var/log/cloudstack/agent from install of 
> cloudstack-agent-4.5.0-SNAPSHOT.el7.x86_64 conflicts with file from package 
> cloudstack-management-4.5.0-SNAPSHOT.el7.x86_64
> Error Summary
> -
> Done



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Damodar Reddy T (JIRA)]

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

Damodar Reddy T edited comment on CLOUDSTACK-7316 at 9/2/14 11:10 AM:
--

Problem:
-
Usage Server was not starting when we enable DB Encryption due to not able to 
find "key" file in the class path when we install it on the same machine where 
management server was installed.
Analysis:
-
Due to changes that are happened to, how cloudstack loads "key" file (earlier 
it used load key file from the hard coded absolute path 
"/etc/cloudstack/management/key") to read it from the class path, when we 
install usage server on the same machine where management server was installed 
it is not able to find the file "key" in the class path of the usage server 
which is "/etc/cloudstack/usage".
Proposed Solution:

During installation of the Usage server, if it is getting installed on the same 
machine where management server was installed add an alias to 
"/etc/cloudstack/management/key" in "/etc/cloudstacl/usage" as "key" if it 
exists.
QA Notes:
---
The default installation of the management server enables file based DB 
encryption so no need to enable it explicitly.


was (Author: damoder.reddy):
Problem:
-
Usage Server was not starting when we enable DB Encryption due to not able to 
find "key" file in the class path when we install it on the same machine where 
management server was installed.
Analysis:
-
Due to changes that are happened to, how CCP loads "key" file (earlier it used 
load key file from the hard coded absolute path 
"/etc/cloudstack/management/key") to read it from the class path, when we 
install usage server on the same machine where management server was installed 
it is not able to find the file "key" in the class path of the usage server 
which is "/etc/cloudstack/usage".
Proposed Solution:

During installation of the Usage server, if it is getting installed on the same 
machine where management server was installed add an alias to 
"/etc/cloudstack/management/key" in "/etc/cloudstacl/usage" as "key" if it 
exists.
QA Notes:
---
The default installation of the management server enables file based DB 
encryption so no need to enable it explicitly.

> hitting java.lang.reflect.InvocationTargetException while starting usage 
> server
> ---
>
> Key: CLOUDSTACK-7316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: usage.tar.gz
>
>
> Repro steps:
> Install MS and usage server
> Start MS and usage server
> Bug:
> Usage server will stop after starting
> usage log shows :
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'vmDiskUsageParser': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
> at 
> org.sprin

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

[Damodar Reddy T (JIRA)]

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

Damodar Reddy T resolved CLOUDSTACK-7316.
-
Resolution: Fixed

Problem:
-
Usage Server was not starting when we enable DB Encryption due to not able to 
find "key" file in the class path when we install it on the same machine where 
management server was installed.
Analysis:
-
Due to changes that are happened to, how CCP loads "key" file (earlier it used 
load key file from the hard coded absolute path 
"/etc/cloudstack/management/key") to read it from the class path, when we 
install usage server on the same machine where management server was installed 
it is not able to find the file "key" in the class path of the usage server 
which is "/etc/cloudstack/usage".
Proposed Solution:

During installation of the Usage server, if it is getting installed on the same 
machine where management server was installed add an alias to 
"/etc/cloudstack/management/key" in "/etc/cloudstacl/usage" as "key" if it 
exists.
QA Notes:
---
The default installation of the management server enables file based DB 
encryption so no need to enable it explicitly.

> hitting java.lang.reflect.InvocationTargetException while starting usage 
> server
> ---
>
> Key: CLOUDSTACK-7316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: usage.tar.gz
>
>
> Repro steps:
> Install MS and usage server
> Start MS and usage server
> Bug:
> Usage server will stop after starting
> usage log shows :
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'vmDiskUsageParser': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at 
> org.springframewo

[jira] [Commented] (CLOUDSTACK-7463) UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118085#comment-14118085
 ] 

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

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

CLOUDSTACK-7463: UI: Domain Admin UI shows 'Add LDAP Users' button (should not 
be shown)

Signed-off-by: Rajani Karuturi 


> UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)
> ---
>
> Key: CLOUDSTACK-7463
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7463
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Gabor Apati-Nagy
>Assignee: Gabor Apati-Nagy
> Fix For: 4.5.0
>
>
> Domain Admin UI shows the 'add ldap users' button. Trying to add LDAP users 
> will show an empty screen (even if LDAP is configured) and an error will be 
> displayed "the given command does not exist or it is not available for user".
> This makes sense as Domain Admin cannot use the importLdapUsers API call, 
> only ROOT Admin.
> The button should be removed for Domain Admins
> Steps to reproduce:
> 1) create LDAP integration
> 2) access as Domain Admin User of a sub-Domain
> 3) note the 'Add LDAP users' button
> 4) Try to add an LDAP user and note the error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[ASF subversion and git services (JIRA)]

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

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

Commit 51e0488e5c07595219142fb2f954726f72e0adf2 in cloudstack's branch 
refs/heads/master from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=51e0488 ]

CLOUDSTACK-7316: Usage Server is not getting started when we install it on 
management server. This is happening when encryption is enabled. For usage 
server it is not able to get key file in the classpath.


> hitting java.lang.reflect.InvocationTargetException while starting usage 
> server
> ---
>
> Key: CLOUDSTACK-7316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Damodar Reddy T
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: usage.tar.gz
>
>
> Repro steps:
> Install MS and usage server
> Start MS and usage server
> Bug:
> Usage server will stop after starting
> usage log shows :
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'vmDiskUsageParser': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
>  BeanPostProcessor before instantiation of bean failed; nested exception is 
> net.sf.cglib.core.CodeGenerationException: 
> java.lang.ExceptionInInitializerError-->null
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
> at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
> at com.cloud.usage.UsageServer.start(UsageServer.java:57)
> ... 5 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
> autowire field: private com.cloud.usage.dao.UsageDao 
> com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'usageDaoImpl' defined in URL 
> 

[jira] [Updated] (CLOUDSTACK-7463) UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)

[Gabor Apati-Nagy (JIRA)]

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

Gabor Apati-Nagy updated CLOUDSTACK-7463:
-
Status: Reviewable  (was: In Progress)

> UI: Domain Admin UI shows 'Add LDAP Users' button (should not be shown)
> ---
>
> Key: CLOUDSTACK-7463
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7463
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Gabor Apati-Nagy
>Assignee: Gabor Apati-Nagy
> Fix For: 4.5.0
>
>
> Domain Admin UI shows the 'add ldap users' button. Trying to add LDAP users 
> will show an empty screen (even if LDAP is configured) and an error will be 
> displayed "the given command does not exist or it is not available for user".
> This makes sense as Domain Admin cannot use the importLdapUsers API call, 
> only ROOT Admin.
> The button should be removed for Domain Admins
> Steps to reproduce:
> 1) create LDAP integration
> 2) access as Domain Admin User of a sub-Domain
> 3) note the 'Add LDAP users' button
> 4) Try to add an LDAP user and note the error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7453) Network rate field specified with negative value in service offering results in db Exception

[Saksham Srivastava (JIRA)]

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

Saksham Srivastava resolved CLOUDSTACK-7453.

Resolution: Fixed

> Network rate field specified with negative value in service offering results 
> in db Exception
> 
>
> Key: CLOUDSTACK-7453
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7453
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.5.0
>Reporter: Saksham Srivastava
>Assignee: Saksham Srivastava
> Fix For: 4.5.0
>
>
> add service offering, add system service offering:
> enter negative value for  network rate field.
> result: status dialog  displayed   with :
>   DB exception on followed by various DB record fields.
> DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@32ec7dc1: INSERT INTO 
> network_offerings (network_offerings.name, network_offerings.unique_name, 
> network_offerings.display_text, network_offerings.nw_rate, 
> network_offerings.mc_rate, network_offerings.traffic_type, 
> network_offerings.specify_vlan, network_offerings.system_only, 
> network_offerings.service_offering_id, network_offerings.tags, 
> network_offerings.default, network_offerings.availability, 
> network_offerings.state, network_offerings.created, 
> network_offerings.guest_type, network_offerings.dedicated_lb_service, 
> network_offerings.shared_source_nat_service, 
> network_offerings.specify_ip_ranges, network_offerings.sort_key, 
> network_offerings.uuid, network_offerings.redundant_router_service, 
> network_offerings.conserve_mode, network_offerings.elastic_ip_service, 
> network_offerings.eip_associate_public_ip, 
> network_offerings.elastic_lb_service, network_offerings.inline, 
> network_offerings.is_persistent, network_offerings.egress_default_policy, 
> network_offerings.concurrent_connections, 
> network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, 
> network_offerings.internal_lb, network_offerings.public_lb) VALUES 
> (_binary'nw1', _binary'nw1', _binary'nw1', -7, 10, 'Guest', 0, 0, null, null, 
> 0, 'Optional', 'Disabled', '2014-07-17 00:34:41', 'Isolated', 1, 0, 0, 0, 
> _binary'd1305b80-c31e-459b-8499-068261f34bd7', 0, 0, 0, 0, 0, 0, 0, 1, 4096, 
> 0, 0, 0, 1)"} 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-83) hitting exception when trying to take two consecutive snapshot on same volume

[ivan derbenev (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118008#comment-14118008
 ] 

ivan derbenev commented on CLOUDSTACK-83:
-

Update!
CS 4.3
Xenserver 6.2 SP1
got the same issue

> hitting exception when trying to take two consecutive snapshot on same volume
> -
>
> Key: CLOUDSTACK-83
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-83
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: pre-4.0.0
> Environment: Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978
> Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: pre-4.0.0
>
> Attachments: cs-83.tar.gz, management-server.log.2012-09-12.gz
>
>
> create a VM
> Create a snapshot of its root volume
> Once the snapshot is backedup try to take one more snapshot of same volume
> Actual result:
> Gets message Failed to back up snapshot on secondary storage
> MS log shows :
> 2012-09-12 15:16:47,338 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-18:null) submit async job-129, details: AsyncJobVO {id:129, 
> userId: 2, accountId: 2, sessionKey: null, instanceType: Snapshot, 
> instanceId: 20, cmd: com.cloud.api.commands.CreateSnapshotCmd, cmdOriginator: 
> null, cmdInfo: 
> {"id":"20","response":"json","sessionkey":"h4CS2hXNWB/Djj6oc7EqZua14sg\u003d","ctxUserId":"2","_":"1347443206549","volumeid":"8d62449d-b03c-4f27-8c14-9f2e1f2c1cea","ctxAccountId":"2","ctxStartEventId":"446"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 59793358248320, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2012-09-12 15:16:47,339 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-32:job-129) Executing com.cloud.api.commands.CreateSnapshotCmd 
> for job-129
> 2012-09-12 15:16:47,382 DEBUG [agent.transport.Request] 
> (Job-Executor-32:job-129) Seq 2-1053884821: Sending  { Cmd , MgmtId: 
> 59793358248320, via: 2, Ver: v1, Flags: 100011, 
> [{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"5728f1d8-e898-4c27-a698-c3108fafc580","_pool":{"id":200,"uuid":"6ce86454-a33f-3551-a1df-bf9cf191dded","host":"10.147.28.7","path":"/export/home/shweta/asfprimary","port":2049,"type":"NetworkFilesystem"},"_snapshotPath":"8522d3f9-353a-422e-8f4c-b9e9772c47f8","_snapshotName":"cent-snap_ROOT-16_20120912094647","_snapshotId":20,"_vmName":"i-2-16-VM","wait":0}}]
>  }
> 2012-09-12 15:16:47,383 DEBUG [agent.transport.Request] 
> (Job-Executor-32:job-129) Seq 2-1053884821: Executing:  { Cmd , MgmtId: 
> 59793358248320, via: 2, Ver: v1, Flags: 100011, 
> [{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"5728f1d8-e898-4c27-a698-c3108fafc580","_pool":{"id":200,"uuid":"6ce86454-a33f-3551-a1df-bf9cf191dded","host":"10.147.28.7","path":"/export/home/shweta/asfprimary","port":2049,"type":"NetworkFilesystem"},"_snapshotPath":"8522d3f9-353a-422e-8f4c-b9e9772c47f8","_snapshotName":"cent-snap_ROOT-16_20120912094647","_snapshotId":20,"_vmName":"i-2-16-VM","wait":0}}]
>  }
> 2012-09-12 15:16:47,383 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-284:null) Seq 2-1053884821: Executing request
> 2012-09-12 15:16:49,425 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-284:null) Seq 2-1053884821: Response Received:
> 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
> (DirectAgent-284:null) Seq 2-1053884821: Processing:  { Ans: , MgmtId: 
> 59793358248320, via: 2, Ver: v1, Flags: 10, 
> [{"ManageSnapshotAnswer":{"_snapshotPath":"60da197d-3de9-4eb6-8a4c-9032003c45a6","result":true,"wait":0}}]
>  }
> 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
> (Job-Executor-32:job-129) Seq 2-1053884821: Received:  { Ans: , MgmtId: 
> 59793358248320, via: 2, Ver: v1, Flags: 10, { ManageSnapshotAnswer } }
> 2012-09-12 15:16:49,469 DEBUG [agent.transport.Request] 
> (Job-Executor-32:job-129) Seq 2-1053884822: Sending  { Cmd , MgmtId: 
> 59793358248320, via: 2, Ver: v1, Flags: 100011, 
> [{"BackupSnapshotCommand":{"prevSnapshotUuid":"8522d3f9-353a-422e-8f4c-b9e9772c47f8","prevBackupUuid":"a030a6af-9663-461c-b746-8a7a814d9694","isVolumeInactive":false,"vmName":"i-2-16-VM","snapshotId":20,"pool":{"id":200,"uuid":"6ce86454-a33f-3551-a1df-bf9cf191dded","host":"10.147.28.7","path":"/export/home/shweta/asfprimary","port":2049,"type":"NetworkFilesystem"},"primaryStoragePoolNameLabel":"6ce86454-a33f-3551-a1df-bf9cf191dded","snapshotUuid":"60da197d-3de9-4eb6-8a4c-9032003c45a6","snapshotName":"cent-snap_ROOT-16_20120912094647","secondaryStorage

[jira] [Commented] (CLOUDSTACK-7464) Management Server setup doesn't proceed to completion on RHEL7

[John Dilley (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117959#comment-14117959
 ] 

John Dilley commented on CLOUDSTACK-7464:
-

This has nothing to do with RHEL7 - see duplicate bug 
https://issues.apache.org/jira/browse/CLOUDSTACK-7465 which was tested on RHEL 
6.3

The management server fails to start in our deployment, we get the following 
exception in the log file:

{noformat}
Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
INFO: Set web app root system property: 'webapp.root' = 
[/usr/share/cloudstack-management/webapps/client/]
Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing log4j from [classpath:log4j-cloud.xml]
Sep 02, 2014 3:22:33 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of 
class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line -1 
in XML document from URL 
[jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-server-4.5.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-event-bus-context.xml]
 is invalid; nested exception is org.xml.sax.SAXParseException; Premature end 
of file.
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
at 
org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:123)
at 
org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:93)
at 
org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
at 
org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at 
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
at 
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at 
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfi

[jira] [Updated] (CLOUDSTACK-7464) Management Server setup doesn't proceed to completion - org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException

[John Dilley (JIRA)]

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

John Dilley updated CLOUDSTACK-7464:

Summary: Management Server setup doesn't proceed to completion - 
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException  (was: 
Management Server setup doesn't proceed to completion)

> Management Server setup doesn't proceed to completion - 
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException
> -
>
> Key: CLOUDSTACK-7464
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7464
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: catalina.out, localhost.2014-09-02.log, 
> management-server.log, setupManagement.log
>
>
> After installation of management server, and database schema update, the 
> setup is stuck at a point and doesn't proceed further. User will not be able 
> to access the MS URL. The server is listening on port 8080 but a connection 
> won't establish. The traces show that it is stuck at a point in the setup.
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_aeac22f4
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_958692e5
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_90d5183f
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_e8137795
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_1344120a



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7464) Management Server setup doesn't proceed to completion

[Damodar Reddy T (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117963#comment-14117963
 ] 

Damodar Reddy T commented on CLOUDSTACK-7464:
-

yeah it does not like empty xml file.. I have tested just now.. and will be 
uploading patch soon..

> Management Server setup doesn't proceed to completion
> -
>
> Key: CLOUDSTACK-7464
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7464
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: catalina.out, localhost.2014-09-02.log, 
> management-server.log, setupManagement.log
>
>
> After installation of management server, and database schema update, the 
> setup is stuck at a point and doesn't proceed further. User will not be able 
> to access the MS URL. The server is listening on port 8080 but a connection 
> won't establish. The traces show that it is stuck at a point in the setup.
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_aeac22f4
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_958692e5
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_90d5183f
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_e8137795
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_1344120a



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7464) Management Server setup doesn't proceed to completion

[John Dilley (JIRA)]

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

John Dilley updated CLOUDSTACK-7464:

Summary: Management Server setup doesn't proceed to completion  (was: 
Management Server setup doesn't proceed to completion on RHEL7)

> Management Server setup doesn't proceed to completion
> -
>
> Key: CLOUDSTACK-7464
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7464
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: catalina.out, localhost.2014-09-02.log, 
> management-server.log, setupManagement.log
>
>
> After installation of management server, and database schema update, the 
> setup is stuck at a point and doesn't proceed further. User will not be able 
> to access the MS URL. The server is listening on port 8080 but a connection 
> won't establish. The traces show that it is stuck at a point in the setup.
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_aeac22f4
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_958692e5
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_90d5183f
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_e8137795
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_1344120a



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7465) Can't start CCP management server - org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException

[Saksham Srivastava (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117962#comment-14117962
 ] 

Saksham Srivastava commented on CLOUDSTACK-7465:


You are correct, the issue is because of the mentioned commit. Revert of the 
commit will work.

> Can't start CCP management server - 
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException
> -
>
> Key: CLOUDSTACK-7465
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7465
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Priority: Blocker
>
> The management server fails to start in our deployment, we get the following 
> exception in the log file:
> {noformat}
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Set web app root system property: 'webapp.root' = 
> [/usr/share/cloudstack-management/webapps/client/]
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Initializing log4j from [classpath:log4j-cloud.xml]
> Sep 02, 2014 3:22:33 AM org.apache.catalina.core.StandardContext listenerStart
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
> -1 in XML document from URL 
> [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-server-4.5.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-event-bus-context.xml]
>  is invalid; nested exception is org.xml.sax.SAXParseException; Premature end 
> of file.
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
>   at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:123)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:93)
>   at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
>   at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
>   at 
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
>   at 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
>   at 

[jira] [Commented] (CLOUDSTACK-7464) Management Server setup doesn't proceed to completion on RHEL7

[John Dilley (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117961#comment-14117961
 ] 

John Dilley commented on CLOUDSTACK-7464:
-

My guess from the exception is that it doesn't like the (effectively) empty XML 
file added by the commit. I'll see if I can test that.

> Management Server setup doesn't proceed to completion on RHEL7
> --
>
> Key: CLOUDSTACK-7464
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7464
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: catalina.out, localhost.2014-09-02.log, 
> management-server.log, setupManagement.log
>
>
> After installation of management server, and database schema update, the 
> setup is stuck at a point and doesn't proceed further. User will not be able 
> to access the MS URL. The server is listening on port 8080 but a connection 
> won't establish. The traces show that it is stuck at a point in the setup.
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_aeac22f4
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_958692e5
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_90d5183f
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_e8137795
> 2014-09-02 11:17:46,341 INFO  [c.c.u.c.ComponentContext] 
> (localhost-startStop-1:null) Starting 
> com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_1344120a



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7465) Can't start CCP management server - org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException

[John Dilley (JIRA)]

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

John Dilley resolved CLOUDSTACK-7465.
-
Resolution: Duplicate

> Can't start CCP management server - 
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException
> -
>
> Key: CLOUDSTACK-7465
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7465
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Priority: Blocker
>
> The management server fails to start in our deployment, we get the following 
> exception in the log file:
> {noformat}
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Set web app root system property: 'webapp.root' = 
> [/usr/share/cloudstack-management/webapps/client/]
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Initializing log4j from [classpath:log4j-cloud.xml]
> Sep 02, 2014 3:22:33 AM org.apache.catalina.core.StandardContext listenerStart
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
> -1 in XML document from URL 
> [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-server-4.5.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-event-bus-context.xml]
>  is invalid; nested exception is org.xml.sax.SAXParseException; Premature end 
> of file.
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
>   at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:123)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:93)
>   at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
>   at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
>   at 
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
>   at 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
>   at 
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
>   at 
> org.apache.catalina.core.StandardContext.s

[jira] [Comment Edited] (CLOUDSTACK-7465) Can't start CCP management server - org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException

[John Dilley (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117956#comment-14117956
 ] 

John Dilley edited comment on CLOUDSTACK-7465 at 9/2/14 6:59 AM:
-

My guess from the exception is that it doesn't like the (effectively) empty XML 
file. I'll see if I can test that.


was (Author: johnmdilley):
My guess from the exception is that it doesn't like the (effectively) empty XML 
file. I'll see if I can validate that.

> Can't start CCP management server - 
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException
> -
>
> Key: CLOUDSTACK-7465
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7465
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Priority: Blocker
>
> The management server fails to start in our deployment, we get the following 
> exception in the log file:
> {noformat}
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Set web app root system property: 'webapp.root' = 
> [/usr/share/cloudstack-management/webapps/client/]
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Initializing log4j from [classpath:log4j-cloud.xml]
> Sep 02, 2014 3:22:33 AM org.apache.catalina.core.StandardContext listenerStart
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
> -1 in XML document from URL 
> [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-server-4.5.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-event-bus-context.xml]
>  is invalid; nested exception is org.xml.sax.SAXParseException; Premature end 
> of file.
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
>   at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:123)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:93)
>   at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
>   at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
>   at 
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpri

[jira] [Commented] (CLOUDSTACK-7465) Can't start CCP management server - org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException

[John Dilley (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117956#comment-14117956
 ] 

John Dilley commented on CLOUDSTACK-7465:
-

My guess from the exception is that it doesn't like the (effectively) empty XML 
file. I'll see if I can validate that.

> Can't start CCP management server - 
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException
> -
>
> Key: CLOUDSTACK-7465
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7465
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Priority: Blocker
>
> The management server fails to start in our deployment, we get the following 
> exception in the log file:
> {noformat}
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Set web app root system property: 'webapp.root' = 
> [/usr/share/cloudstack-management/webapps/client/]
> Sep 02, 2014 3:22:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: Initializing log4j from [classpath:log4j-cloud.xml]
> Sep 02, 2014 3:22:33 AM org.apache.catalina.core.StandardContext listenerStart
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
> -1 in XML document from URL 
> [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-server-4.5.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-event-bus-context.xml]
>  is invalid; nested exception is org.xml.sax.SAXParseException; Premature end 
> of file.
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
>   at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:123)
>   at 
> org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:93)
>   at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
>   at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
>   at 
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
>   at 
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
>