[jira] [Updated] (CLOUDSTACK-1489) cloudstack agent plugin classpath is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroaki Kawai updated CLOUDSTACK-1489: -- Component/s: KVM cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.2.0 Environment: Linux kvm Reporter: Hiroaki Kawai There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-1489) cloudstack agent plugin classpath is missing
Hiroaki Kawai created CLOUDSTACK-1489: - Summary: cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.0.0, pre-4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.2.0 Environment: Linux kvm Reporter: Hiroaki Kawai There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1489) cloudstack agent plugin classpath is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroaki Kawai updated CLOUDSTACK-1489: -- Affects Version/s: (was: 4.2.0) (was: 4.1.0) cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2 Environment: Linux kvm Reporter: Hiroaki Kawai There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1252) Failed to download default template in VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-1252: - Assignee: Pradeep Soundararajan Failed to download default template in VMware - Key: CLOUDSTACK-1252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1252 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, VMware Affects Versions: 4.1.0 Environment: CentOS6.3 4.1 branch build Hyper visor : VMware Reporter: Rayees Namathponnan Assignee: Pradeep Soundararajan Priority: Blocker Fix For: 4.1.0 Attachments: cloud.rar Step 1 : Created new build from 4.1 branch Step 2 : Install and configured MS server on CentOS 6.3 Step 3 : Prepared system template and created advanced zone Actual result System VM are created, but default templates are not available in template section. I tried to started agent from SSVM, with command service cloudstack-agent start and failed, but command service cloud start works If you look at the SSVM cloud.out (/var/log/cloud/clout.out) you can see class not found exception java.lang.ClassNotFoundException: com.cloud.storage.resource.PremiumSecondaryStorageResource + java -Djavax.net.ssl.trustStore=./certs/realhostip.keystore -mx168m -cp ./:./conf:aopalliance-1.0.jar:apache-log4j-extras-1.1.jar:aspectjrt-1.7.1.jar:aspectjweaver-1.7.1.jar:aws-java-sdk-1.3.21.1.jar:backport-util-concurrent-3.1.jar:bcprov-jdk16-1.46.jar:cglib-nodep-2.2.2.jar:cloud-agent-4.1.0-SNAPSHOT.jar:cloud-api-4.1.0-SNAPSHOT.jar:cloud-console-proxy-4.1.0-SNAPSHOT.jar:cloud-core-4.1.0-SNAPSHOT.jar:cloud-utils-4.1.0-SNAPSHOT.jar:commons-codec-1.6.jar:commons-collections-3.2.1.jar:commons-configuration-1.8.jar:commons-dbcp-1.4.jar:commons-discovery-0.5.jar:commons-httpclient-3.1.jar:commons-lang-2.6.jar:commons-logging-1.1.1.jar:commons-pool-1.6.jar:dom4j-1.6.1.jar:ehcache-1.5.0.jar:ejb-api-3.0.jar:gson-1.7.1.jar:guava-14.0-rc1.jar:httpclient-4.1.jar:httpcore-4.1.jar:jackson-core-asl-1.8.9.jar:jackson-mapper-asl-1.8.9.jar:jasypt-1.9.0.jar:java-ipv6-0.8.jar:javassist-3.12.1.GA.jar:javax.inject-1.jar:javax.persistence-2.0.0.jar:jsch-0.1.42.jar:jsr107cache-1.0.jar:log4j-1.2.16.jar:reflections-0.9.8.jar:spring-aop-3.1.2.RELEASE.jar:spring-asm-3.1.2.RELEASE.jar:spring-beans-3.1.2.RELEASE.jar:spring-context-3.1.2.RELEASE.jar:spring-core-3.1.2.RELEASE.jar:spring-expression-3.1.2.RELEASE.jar:spring-web-3.1.2.RELEASE.jar:trilead-ssh2-build213-svnkit-1.3-patch.jar:xml-apis-1.0.b2.jar com.cloud.agent.AgentShell template=domP type=secstorage host=10.223.49.197 port=8250 name=s-3-VM zone=1 pod=1 guid=s-3-VM resource=com.cloud.storage.resource.PremiumSecondaryStorageResource instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 eth2ip=10.223.243.20 eth2mask=255.255.255.192 gateway=10.223.243.1 public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0 eth1ip=10.223.250.169 eth1mask=255.255.255.192 mgmtcidr=10.223.49.192/26 localgw=10.223.250.129 private.network.device=eth1 eth3ip=10.223.250.156 eth3mask=255.255.255.192 storageip=10.223.250.156 storagenetmask=255.255.255.192 storagegateway=10.223.250.129 internaldns1=10.223.110.254 internaldns2=10.223.110.253 dns1=72.52.126.11 dns2=72.52.126.12 log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.params.DefaultHttpParams). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Unable to start agent: Resource class not found: com.cloud.storage.resource.PremiumSecondaryStorageResource due to: java.lang.ClassNotFoundException: com.cloud.storage.resource.PremiumSecondaryStorageResource Attached cloud.out for reference -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1470) unhandled exception executing api command: deployVirtualMachine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591386#comment-13591386 ] Sudha Ponnaganti commented on CLOUDSTACK-1470: -- Min, if done, can you move defect to resolved state unhandled exception executing api command: deployVirtualMachine --- Key: CLOUDSTACK-1470 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1470 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: advanced zone hypervisor: XS6.1 MGMT SERVER: RHEL6.3 Reporter: Srikanteswararao Talluri Assignee: Min Chen Priority: Blocker Fix For: 4.1.0 Attachments: management-server.zip, SMlog On advanced zone deployment, 1. deploy a virtual machine unhandled exception executing api command: deployVirtualMachine java.lang.ClassCastException: $Proxy301 cannot be cast to org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl at org.apache.cloudstack.platform.orchestration.CloudOrchestrator.createVirtualMachine(CloudOrchestrator.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) at $Proxy286.createVirtualMachine(Unknown Source) at com.cloud.vm.UserVmManagerImpl.createVirtualMachine(UserVmManagerImpl.java:3378) at com.cloud.vm.UserVmManagerImpl.createAdvancedVirtualMachine(UserVmManagerImpl.java:3095) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) at
Re: Discuss changing the project bylaws for the PMC Chair voting process
On 02/03/2013, at 2:44 AM, Chip Childers chip.child...@sungard.com wrote: OK - I'm going to draft this up and start a vote now. I don't want to derail the voting process, but would like to clarify this part: --- recommend a new chair through consensus via a lazy 2/3 majority voting method. In the case that consensus is not achieved, the PMC will vote for a chair using Single Transferable Vote (STV) voting. --- At first, I thought the first part meant voting on a number of candidates - but reading this thread it seems you meant: - take nominations, discussion ensues - if there is one name settled vote to confirm the decision to present to the board - if there's not a single name, then use STV Is that right? It may need a bit of clarification on what the first vote is about - but I don't think that should change the vote in progress. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
RE: [VOTE] Change the project bylaws to modify the PMC Chair voting process and add a term length
+1 -Original Message- From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] Sent: Saturday, March 02, 2013 6:52 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [VOTE] Change the project bylaws to modify the PMC Chair voting process and add a term length +1 (binding) -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, March 01, 2013 8:17 AM To: cloudstack-dev@incubator.apache.org Subject: [VOTE] Change the project bylaws to modify the PMC Chair voting process and add a term length Hi all, As previously discussed [1], we'd like to make a change to our bylaws [2] to modify the method of selecting a PMC chair. We also want to add a term for the chair. [1] http://markmail.org/message/ifwwce657u36yuwz [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudS ta ck +Project+Bylaws Below are the specific changes I'd like you to vote on: (1) A change to bylaw section 2.4.5 as follows: CURRENT: 2.4.5. If the current chair of the PMC resigns, the PMC votes to recommend a new chair using Single Transferable Vote (STV) voting. See http://wiki.apache.org/general/BoardVoting for specifics. The decision must be ratified by the Apache board. PROPOSED: 2.4.5. If the current chair of the PMC resigns, or the term of the current chair expires, the PMC votes to recommend a new chair through consensus via a lazy 2/3 majority voting method. In the case that consensus is not achieved, the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due to the fact that the discussions are about specific individuals, this vote would be held on the cloudstack-private mail list. The decision must be ratified by the Apache board. (2) The addition of a new bylaw section: 2.4.6: PROPOSED: 2.4.6. The role of PMC chair will have a one year term. The intention of this term is to allow for a rotation of the role amongst the PMC members. This intention does not prohibit the PMC from selecting the same chair to serve consecutive terms. Per our bylaws (section 3.4.9), this change requires a lazy majority of PMC members to pass. The whole community is encouraged to vote on this issue! This vote will be open for at least 72 hours. Please respond with one of the following: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks! -chip
[jira] [Created] (CLOUDSTACK-1490) 4.1 deb management fails to start due to tomcat dep problems
Noa Resare created CLOUDSTACK-1490: -- Summary: 4.1 deb management fails to start due to tomcat dep problems Key: CLOUDSTACK-1490 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1490 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Noa Resare When building the latest off 4.1 (38e06631d242ca2ba232e5c75ae853de15c51043) on a Ubuntu 12.04LTS and installing cloudstack-management the invocation of '/etc/init.d/cloudstack-management start' fails. In syslog I see the following: code Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.net.URLClassLoader$1.run(URLClassLoader.java:217) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.security.AccessController.doPrivileged(Native Method) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.net.URLClassLoader.findClass(URLClassLoader.java:205) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.ClassLoader.loadClass(ClassLoader.java:321) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:216) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:275) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.reflect.Method.invoke(Method.java:616) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212) /code -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Discuss changing the project bylaws for the PMC Chair voting process
On Mar 2, 2013, at 7:40 AM, Brett Porter br...@apache.org wrote: On 02/03/2013, at 2:44 AM, Chip Childers chip.child...@sungard.com wrote: OK - I'm going to draft this up and start a vote now. I don't want to derail the voting process, but would like to clarify this part: --- recommend a new chair through consensus via a lazy 2/3 majority voting method. In the case that consensus is not achieved, the PMC will vote for a chair using Single Transferable Vote (STV) voting. --- At first, I thought the first part meant voting on a number of candidates - but reading this thread it seems you meant: - take nominations, discussion ensues - if there is one name settled vote to confirm the decision to present to the board - if there's not a single name, then use STV Is that right? It may need a bit of clarification on what the first vote is about - but I don't think that should change the vote in progress. That was the intent, yes. I'll propose a slight clarification to the wording in the vote thread. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: [VOTE] Change the project bylaws to modify the PMC Chair voting process and add a term length
+1 -abhi On 02-Mar-2013, at 6:27 AM, Alex Karasulu akaras...@apache.org wrote: +1 (binding) [X] +1 approve -- Best Regards, -- Alex
Re: Review Request: Ensure RAT does not report marvin generated files as noncompliant in developer environment
Prasanna, You asked to move this to 4.1, but is it a blocker or critical fix in your opinion? The risk looks low to me. Opinion? On Mar 2, 2013, at 6:27 AM, Prasanna Santhanam prasanna.santha...@citrix.com wrote: This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9707/ On March 2nd, 2013, 11:16 a.m., *Prasanna Santhanam* wrote: Yes, good to apply. Thanks 6a1ecae552e8857c8e97c283962d14db4479a9a1 (master) Pl. cherry-pick to 4.1 - Prasanna On March 1st, 2013, 9:15 p.m., Chiradeep Vittal wrote: Review request for Chip Childers and Prasanna Santhanam. By Chiradeep Vittal. *Updated March 1, 2013, 9:15 p.m.* Description Ensure RAT does not report marvin generated files as noncompliant in developer environment Testing mvn clean install and mvn --projects=org.apache.cloudstack:cloudstack org.apache.rat:apache-rat-plugin:0.8:check Diffs - pom.xml (dde205f6d7cada71fde8ac805394228810a421e2) - tools/marvin/marvin/codegenerator.py (cce91008dba0b15fa2070daf19f067aa08b86ed6) View Diff https://reviews.apache.org/r/9707/diff/
Re: (CLOUDSTACK-1252) Failed to download default template in VMware
Hugo, Can you take a look at this? On Mar 1, 2013, at 11:27 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, Hugo Please see comment from Kelven regarding this issue pointing to RPM build. Can someone familiar with RPM investigate? Animesh -Original Message- From: Kelven Yang (JIRA) [mailto:j...@apache.org] Sent: Friday, March 01, 2013 5:55 PM To: Animesh Chaturvedi Subject: [jira] [Commented] (CLOUDSTACK-1252) Failed to download default template in VMware [ https://issues.apache.org/jira/browse/CLOUDSTACK-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591204#comment-13591204 ] Kelven Yang commented on CLOUDSTACK-1252: - This is what I've done to check the problem 1) Check RPM cloud.spec and found out that target ISO installation path is at /usr/share/cloudstack-share/vms and the built-in path in Java is not the same as RPM spec, This leads to CLOUDSTACK-1262 2) Check an existing RPM setup, search for systemvm.iso using rpm -qal | grep cloud mount -t iso9660 -o loop /usr/share/cloudstack-common/.../systemvm.iso /mnt unzip -l systemvm.zip and found out that the content inside the ISO does not contain files for VMware The problem seems to come from the RPM build that is for non-oss packages, RPM build should issue maven command with following options mvn -P systemvm -Dnonoss Could someone who is familar with RPM build to take a look? Failed to download default template in VMware - Key: CLOUDSTACK-1252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1252 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, VMware Affects Versions: 4.1.0 Environment: CentOS6.3 4.1 branch build Hyper visor : VMware Reporter: Rayees Namathponnan Assignee: Kelven Yang Priority: Blocker Fix For: 4.1.0 Attachments: cloud.rar Step 1 : Created new build from 4.1 branch Step 2 : Install and configured MS server on CentOS 6.3 Step 3 : Prepared system template and created advanced zone Actual result System VM are created, but default templates are not available in template section. I tried to started agent from SSVM, with command service cloudstack-agent start and failed, but command service cloud start works If you look at the SSVM cloud.out (/var/log/cloud/clout.out) you can see class not found exception java.lang.ClassNotFoundException: com.cloud.storage.resource.PremiumSecondaryStorageResource + java -Djavax.net.ssl.trustStore=./certs/realhostip.keystore -mx168m + -cp + ./:./conf:aopalliance-1.0.jar:apache-log4j-extras-1.1.jar:aspectjrt- + 1.7.1.jar:aspectjweaver-1.7.1.jar:aws-java-sdk-1.3.21.1.jar:backport + -util-concurrent-3.1.jar:bcprov-jdk16-1.46.jar:cglib-nodep-2.2.2.jar + :cloud-agent-4.1.0-SNAPSHOT.jar:cloud-api-4.1.0-SNAPSHOT.jar:cloud-c + onsole-proxy-4.1.0-SNAPSHOT.jar:cloud-core-4.1.0-SNAPSHOT.jar:cloud- + utils-4.1.0-SNAPSHOT.jar:commons-codec-1.6.jar:commons-collections-3 + .2.1.jar:commons-configuration-1.8.jar:commons-dbcp-1.4.jar:commons- + discovery-0.5.jar:commons-httpclient-3.1.jar:commons-lang-2.6.jar:co + mmons-logging-1.1.1.jar:commons-pool-1.6.jar:dom4j-1.6.1.jar:ehcache + -1.5.0.jar:ejb-api-3.0.jar:gson-1.7.1.jar:guava-14.0-rc1.jar:httpcli + ent-4.1.jar:httpcore-4.1.jar:jackson-core-asl-1.8.9.jar:jackson-mapp + er-asl-1.8.9.jar:jasypt-1.9.0.jar:java-ipv6-0.8.jar:javassist-3.12.1 + .GA.jar:javax.inject-1.jar:javax.persistence-2.0.0.jar:jsch-0.1.42.j + ar:jsr107cache-1.0.jar:log4j-1.2.16.jar:reflections-0.9.8.jar:spring + -aop-3.1.2.RELEASE.jar:spring-asm-3.1.2.RELEASE.jar:spring-beans-3.1 + .2.RELEASE.jar:spring-context-3.1.2.RELEASE.jar:spring-core-3.1.2.RE + LEASE.jar:spring-expression-3.1.2.RELEASE.jar:spring-web-3.1.2.RELEA + SE.jar:trilead-ssh2-build213-svnkit-1.3-patch.jar:xml-apis-1.0.b2.ja + r com.cloud.agent.AgentShell template=domP type=secstorage + host=10.223.49.197 port=8250 name=s-3-VM zone=1 pod=1 guid=s-3-VM + resource=com.cloud.storage.resource.PremiumSecondaryStorageResource + instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 + eth2ip=10.223.243.20 eth2mask=255.255.255.192 gateway=10.223.243.1 + public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0 + eth1ip=10.223.250.169 eth1mask=255.255.255.192 + mgmtcidr=10.223.49.192/26 localgw=10.223.250.129 + private.network.device=eth1 eth3ip=10.223.250.156 + eth3mask=255.255.255.192 storageip=10.223.250.156 + storagenetmask=255.255.255.192 storagegateway=10.223.250.129 + internaldns1=10.223.110.254 internaldns2=10.223.110.253 + dns1=72.52.126.11 dns2=72.52.126.12 log4j:WARN No appenders could be found for logger
Re: Review Request: Ensure RAT does not report marvin generated files as noncompliant in developer environment
Not a blocker/critical. I thought this was a patch request. diregard the cherry-pick request. On 2 March 2013 18:39, Chip Childers chip.child...@sungard.com wrote: Prasanna, You asked to move this to 4.1, but is it a blocker or critical fix in your opinion? The risk looks low to me. Opinion? On Mar 2, 2013, at 6:27 AM, Prasanna Santhanam prasanna.santha...@citrix.com wrote: This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9707/ On March 2nd, 2013, 11:16 a.m., *Prasanna Santhanam* wrote: Yes, good to apply. Thanks 6a1ecae552e8857c8e97c283962d14db4479a9a1 (master) Pl. cherry-pick to 4.1 - Prasanna On March 1st, 2013, 9:15 p.m., Chiradeep Vittal wrote: Review request for Chip Childers and Prasanna Santhanam. By Chiradeep Vittal. *Updated March 1, 2013, 9:15 p.m.* Description Ensure RAT does not report marvin generated files as noncompliant in developer environment Testing mvn clean install and mvn --projects=org.apache.cloudstack:cloudstack org.apache.rat:apache-rat-plugin:0.8:check Diffs - pom.xml (dde205f6d7cada71fde8ac805394228810a421e2) - tools/marvin/marvin/codegenerator.py (cce91008dba0b15fa2070daf19f067aa08b86ed6) View Diff https://reviews.apache.org/r/9707/diff/
Re: [DOCS][TRANSLATION] Update
On Mar 2, 2013, at 8:13 AM, Milamber milam...@apache.org wrote: Hello, I've translate last sentences/words for French translation on Transifex for Cloudstack UI. Woot! Thank you! I've made a full review of all elements (fixed some typo, translate some words in sentences, etc.) You can make a update of resources files. Milamber Le 23/02/2013 20:32, Sebastien Goasguen a ecrit : Hi, Quick update on translation. We had a complete translation of the runbook in Italian. Awesome ! Things are progressing, but I would like everyone to forward this tutorial: http://www.slideshare.net/sebastiengoasguen/how-to-translate-apache-cloudstack-docs To your friends and colleagues who speak something else than english. Our friends in China and Japan especially have a chance to finish the complete translation before 4.1, this would be huge. Since the complete translation is a lot of work, some of you may want to focus on the runbook and the UI. It's shorter. Keep a it !!! Cheers, -Sebastien
Review Request: 4.1 deb packaging tomcat fixes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules d537d86 packaging/debian/replace.properties d891e79 Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
[jira] [Commented] (CLOUDSTACK-1490) 4.1 deb management fails to start due to tomcat dep problems
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591407#comment-13591407 ] Noa Resare commented on CLOUDSTACK-1490: Debugging this was no fun, as the tomcat installation is a hairball inside a hairball. A minimally invasive way of fixing the two problems (and re-enable logging) is available at https://reviews.apache.org/r/9714/ and in the noa/deb_tomcat_fix_4.1 branch of the https://github.com/noaresare/incubator-cloudstack.git repo 4.1 deb management fails to start due to tomcat dep problems Key: CLOUDSTACK-1490 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1490 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Noa Resare When building the latest off 4.1 (38e06631d242ca2ba232e5c75ae853de15c51043) on a Ubuntu 12.04LTS and installing cloudstack-management the invocation of '/etc/init.d/cloudstack-management start' fails. In syslog I see the following: code Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.net.URLClassLoader$1.run(URLClassLoader.java:217) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.security.AccessController.doPrivileged(Native Method) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.net.URLClassLoader.findClass(URLClassLoader.java:205) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.ClassLoader.loadClass(ClassLoader.java:321) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:216) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:275) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at java.lang.reflect.Method.invoke(Method.java:616) Jan 6 20:00:29 ubuntu1204lts jsvc.exec[64611]: #011at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212) /code -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DOCS][TRANSLATION] Update
Hello, I've translate last sentences/words for French translation on Transifex for Cloudstack UI. I've made a full review of all elements (fixed some typo, translate some words in sentences, etc.) You can make a update of resources files. Milamber Le 23/02/2013 20:32, Sebastien Goasguen a ecrit : Hi, Quick update on translation. We had a complete translation of the runbook in Italian. Awesome ! Things are progressing, but I would like everyone to forward this tutorial: http://www.slideshare.net/sebastiengoasguen/how-to-translate-apache-cloudstack-docs To your friends and colleagues who speak something else than english. Our friends in China and Japan especially have a chance to finish the complete translation before 4.1, this would be huge. Since the complete translation is a lot of work, some of you may want to focus on the runbook and the UI. It's shorter. Keep a it !!! Cheers, -Sebastien
Re: Review Request: 4.1 deb packaging tomcat fixes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/#review17302 --- Seems partially right. This is against the 4.1 branch, correct? Since the logfile fixes are already in master. Best practice is to check master first and cherry pick stuff to 4.1 - Wido den Hollander On March 2, 2013, 1:55 p.m., Noa Resare wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 1:55 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules d537d86 packaging/debian/replace.properties d891e79 Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: [ACS41][Patch Request] Update cloud user's home dir on cloudstack-management RPM install
Is the hash right? On 4.1 branch: # git cherry-pick 6317f0bd33605c4943dcf472415e9d5c7a443d93 fatal: bad object 6317f0bd33605c4943dcf472415e9d5c7a443d93 On Fri, Mar 01, 2013 at 05:58:34PM -0700, Marcus Sorensen wrote: It can go under CLOUDSTACK-1201, since it's the same issue, just in the case of upgrade rather than fresh install. On Fri, Mar 1, 2013 at 5:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I can create one. I just didn't realize we needed a bug ID for every time we touch the code. I'll look and see if there's already a general one about making RPM builds work. On Fri, Mar 1, 2013 at 5:51 PM, Chip Childers chip.child...@sungard.com wrote: Bug ID? On Mar 1, 2013, at 7:51 PM, Marcus Sorensen shadow...@gmail.com wrote: This adds to cloud.spec post installation of cloudstack-management. It updates the cloud user's home dir to the new location if it finds that the cloud user's home is set to the old location. master 6317f0bd33605c4943dcf472415e9d5c7a443d93 applies cleanly to 4.1 as of now.
Re: copying scripts in client/pom.xml
On Fri, Mar 01, 2013 at 03:20:38PM -0800, Frank Zhang wrote:
Hi Hugo:
I noticed your recent change as below. It will cause bug
https://issues.apache.org/jira/browse/CLOUDSTACK-1304 that I have fixed some
days ago
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 271)
copy todir=${basedir}/target/generated-webapp/WEB-INF/classes/scripts
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 272)
fileset dir=${basedir}/../scripts /
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 273)
/copy
my fixes basically does:
exec executable=cp
arg value=-r /
arg value=${basedir}/../scripts /
arg
value=${basedir}/target/generated-webapp/WEB-INF/classes/scripts /
/exec
Is there any special reason you changed it back? Thank you
Frank / Hugo - Should we reopen CLOUDSTACK-1304?
I'd also suggest that the description of the bug makes it a bit higher
than the Major designation (i.e.: we should fix it in 4.1).
Re: [ACS41][Patch Request] Update cloud user's home dir on cloudstack-management RPM install
On Fri, Mar 01, 2013 at 05:58:34PM -0700, Marcus Sorensen wrote: It can go under CLOUDSTACK-1201, since it's the same issue, just in the case of upgrade rather than fresh install. Done. Thanks Marcus. On Fri, Mar 1, 2013 at 5:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I can create one. I just didn't realize we needed a bug ID for every time we touch the code. I'll look and see if there's already a general one about making RPM builds work. On Fri, Mar 1, 2013 at 5:51 PM, Chip Childers chip.child...@sungard.com wrote: Bug ID? On Mar 1, 2013, at 7:51 PM, Marcus Sorensen shadow...@gmail.com wrote: This adds to cloud.spec post installation of cloudstack-management. It updates the cloud user's home dir to the new location if it finds that the cloud user's home is set to the old location. master 6317f0bd33605c4943dcf472415e9d5c7a443d93 applies cleanly to 4.1 as of now.
[jira] [Reopened] (CLOUDSTACK-1262) Failed to Prepare Secondary Storage in VMware,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chip Childers reopened CLOUDSTACK-1262:
---
I wasn't able to find a patch on reviewboard for this, and attempting to
cherry-pick resulted in a conflict:
From 4.1 branch:
# git cherry-pick cec4d8b59c33858c99a4ead29b66d9aff5f0af6f
error: could not apply cec4d8b... CLOUDSTACK-1262: update default built-in
systemvm.iso search patch to be consistent with RPM location
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add paths' or 'git rm paths'
hint: and commit the result with 'git commit'
Please submit a patch to reviewboard that applies cleanly to the 4.1 branch.
Thanks Kelvin!
Failed to Prepare Secondary Storage in VMware,
---
Key: CLOUDSTACK-1262
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1262
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: 4.1.0, 4.2.0
Environment: CentOS 6.3
Vmware
Reporter: Rayees Namathponnan
Assignee: Kelven Yang
Priority: Blocker
Fix For: 4.1.0, 4.2.0
Attachments: management-server.log
Failed to prepare secondary storage VM in VMware, since we are expecting
systemvm.iso is available at /usr/lib64/cloud/common//vms/systemvm.iso
instead of /usr/share/cloudstack-common/vms/systemvm.iso
/plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
private File getSystemVMPatchIsoFile() {
// locate systemvm.iso
URL url =
this.getClass().getProtectionDomain().getCodeSource().getLocation();
File file = new File(url.getFile());
File isoFile = new File(file.getParent() + /vms/systemvm.iso);
if (!isoFile.exists()) {
isoFile = new File(/usr/lib64/cloud/common/ +
/vms/systemvm.iso);
if (!isoFile.exists()) {
isoFile = new File(/usr/lib/cloud/common/ +
/vms/systemvm.iso);
}
}
return isoFile;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Failed to addCluster with latest master code
On Fri, Mar 01, 2013 at 06:03:58PM -0800, Min Chen wrote: Hi there, In preparing merging my feature branch vim51_win8 to master, I rebased with latest master code, then my testing immediately failed at addCluster with the following stack trace: 2013-03-01 17:34:18,953 DEBUG [cloud.network.NetworkModelImpl] (552681680@qtp-144013098-6:null) Failed to retrieve the default label for public traffic.zone: 1 hypervisor: VMware due to: Unable to find the default physical network with traffic=Public in zone id=1. 2013-03-01 17:34:19,305 ERROR [cloud.api.ApiServer] (552681680@qtp-144013098-6:null) unhandled exception executing api command: addCluster java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:571) at java.util.ArrayList.get(ArrayList.java:349) at com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:214) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:54) at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) This exception is thrown from this piece of code recently checked in related to Vmware Distributed Vswitch feature: List? extends PhysicalNetwork pNetworkListGuestTraffic = _netmgr.getPhysicalNtwksSupportingTrafficType(dcId, TrafficType.Guest); List? extends PhysicalNetwork pNetworkListPublicTraffic = _netmgr.getPhysicalNtwksSupportingTrafficType(dcId, TrafficType.Public); // Public network would be on single physical network hence getting first object of the list would suffice. PhysicalNetwork pNetworkPublic = pNetworkListPublicTraffic.get(0); In this case, pNetworkListPublicTraffic list is empty, thus index out of range error is thrown next. Does anybody see this issue? Sateesh, do we need to setup Vmware host differently than before with your new code? In previous code, it can always successfully find vSwitch0 to use. Due to this issue, I am holding off my merge until this is resolved. Thanks -min Thanks for not moving forward with the merge Min! Please open a blocker bug for 4.2, and assign it to the author of that commit. -chip
Re: How do we meter IPSEC data separate from other data for Remote Access VPN
On Fri, Mar 01, 2013 at 06:17:00PM -0800, Chandan Purushothama wrote: I referred to the feature presented at https://issues.apache.org/jira/browse/CLOUDSTACK-759 . May I know how is the metering of IPSEC data done on CloudStack. May I know where can I find the Functional Specification for this feature to understand how this feature works, Thank you, Chandan. Kishan, Can you answer this please? -chip
[jira] [Commented] (CLOUDSTACK-1487) cloudstack-setup-agent fails to set private.network.device on KVM host add
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591486#comment-13591486 ] ASF subversion and git services commented on CLOUDSTACK-1487: - Commit ee68560fe14edd420727118fb3d5f6da72313844 in branch refs/heads/4.1 from Chip Childers chip.child...@gmail.com [ https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;h=ee68560 ] Summary: Add EOF to agent.properties for proper parsing Detail: lack of newline at end of file was keeping cloudstack-setup-agent from properly editing/creating new config. BUG-ID: CLOUDSTACK-1487 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1362191198 -0700 cloudstack-setup-agent fails to set private.network.device on KVM host add -- Key: CLOUDSTACK-1487 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1487 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.1.0 Environment: CentOS 6.3, KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Priority: Blocker Fix For: 4.1.0 When setting up zone and adding a host, the management server connects to the host and runs cloudstack-setup-agent. Per the management server log: cloudstack-setup-agent -m 172.17.10.10 -z 1 -p 1 -c 1 -g 7e59f3ee-6112-301e-a361-ee475c63215a -a --pubNic=cloudbr1 --prvNic=cloudbr0 --guestNic=cloudbr0 output:CloudStack Agent setup is done! but in the /etc/cloudstack/agent/agent.properties, private.network.device is not set. This leaves people with a broken install with all sorts of symptoms that one might create bug reports for. I'm not familiar enough with python or all of the included cloudstack libraries to track it down. see resulting file: guest.network.device=cloudbr0 workers=5 port=8250 resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource pod=1 zone=1 guid=7e59f3ee-6112-301e-a361-ee475c63215a cluster=1 public.network.device=cloudbr1 local.storage.uuid=d6818058-ccad-4d8e-8473-7f7a0cfe3b7c domr.scripts.dir=scripts/network/domr/kvm host=172.17.10.10 LibvirtComputingResource.id=1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [ACS41][Patch Request] agent.properties from RPM is blocking proper agent setup
On Fri, Mar 01, 2013 at 07:37:24PM -0700, Marcus Sorensen wrote: Please cherry pick to 4.1, it allows agent setup to complete properly when host is added. This might actually have something to do with all of the 'no private.network.device in agent.properties' issues popping up from the testers. Applied and pushed! Can you do us a favor, and open bugs before committing for issues like this? Especially if it's actually as bad as described. Then, you can add the CLOUDSTACK- number as the start of the commit message. Obviously, all you did was add a newline... but it's helpful to be able to track things like above. commit e08281838a428a26f1993519de96fc45a26c0920 Author: Marcus Sorensen mar...@betterservers.com Date: Fri Mar 1 19:26:38 2013 -0700 Summary: Add EOF to agent.properties for proper parsing Detail: lack of newline at end of file was keeping cloudstack-setup-agent from properly editing/creating new config. BUG-ID: CLOUDSTACK-1487 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1362191198 -0700
Re: [ACS41][Patch Request] agent.properties from RPM is blocking proper agent setup
The bug was created a few hours before the commit. I didn't even know I'd end up fixing it. I thought we had standardized on a BUG-ID: header in commits, way back in October or so when Rohit was asking for better commit messages. We even created a pre-commit hook people could use to prepopulate their commits with common fields. On Sat, Mar 2, 2013 at 12:25 PM, Chip Childers chip.child...@sungard.com wrote: On Fri, Mar 01, 2013 at 07:37:24PM -0700, Marcus Sorensen wrote: Please cherry pick to 4.1, it allows agent setup to complete properly when host is added. This might actually have something to do with all of the 'no private.network.device in agent.properties' issues popping up from the testers. Applied and pushed! Can you do us a favor, and open bugs before committing for issues like this? Especially if it's actually as bad as described. Then, you can add the CLOUDSTACK- number as the start of the commit message. Obviously, all you did was add a newline... but it's helpful to be able to track things like above. commit e08281838a428a26f1993519de96fc45a26c0920 Author: Marcus Sorensen mar...@betterservers.com Date: Fri Mar 1 19:26:38 2013 -0700 Summary: Add EOF to agent.properties for proper parsing Detail: lack of newline at end of file was keeping cloudstack-setup-agent from properly editing/creating new config. BUG-ID: CLOUDSTACK-1487 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1362191198 -0700
[jira] [Reopened] (CLOUDSTACK-1304) mvn -pl :cloud-client-ui jetty:run strips permission of files in script/
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hugo Trippaers reopened CLOUDSTACK-1304:
I reverted this commit because it breaks the system for developers who use an
operating system that has no cp or mkdir command (the mkdir was later added by
Rohit)
I did not notice the original issue because the executable bit is not an issue
on windows systems. We should find an alternative way to do this to solve this
problem in a way that works on all operating systems. It's mainly a developer
problem as the permissions are set using the packaging scripts for deployments.
A check if mkdir and cp exists before doing the copy should work i think, but
maybe there is an ant task that will take care of the permissions on unix based
systems,
mvn -pl :cloud-client-ui jetty:run strips permission of files in script/
---
Key: CLOUDSTACK-1304
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1304
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0
Reporter: frank zhang
Assignee: frank zhang
Fix For: 4.1.0
mvn -pl :cloud-client-ui jetty:run calls ant task copy to copy files
under script/ to ${basedir}/target/generated-webapp/WEB-INF/classes/scripts
it will strip all permission on files to default system permission which
erases execution bit on script. the reason is
Unix Note: File permissions are not retained when files are copied; they end
up with the default UMASK permissions instead. This is caused by the lack of
any means to query or set file permissions in the current Java runtimes. If
you need a permission-preserving copy function, use exec executable=cp ...
instead.
http://ant.apache.org/manual/Tasks/copy.html
this issue will prevent mgmt server executes any shell script due to lacking
of execution permission on script
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [ACS41][Patch Request] agent.properties from RPM is blocking proper agent setup
On Sat, Mar 02, 2013 at 12:28:55PM -0700, Marcus Sorensen wrote: The bug was created a few hours before the commit. I didn't even know I'd end up fixing it. I thought we had standardized on a BUG-ID: header in commits, way back in October or so when Rohit was asking for better commit messages. We even created a pre-commit hook people could use to prepopulate their commits with common fields. You're totally right! For some reason, I didn't see the bug ID. Blind to the exact info I was looking for I guess!
RE: copying scripts in client/pom.xml
Hey Frank,
I reopened the ticket with the following comment:
I reverted this commit because it breaks the system for developers who use an
operating system that has no cp or mkdir command (the mkdir was later added by
Rohit)
I did not notice the original issue because the executable bit is not an issue
on windows systems. We should find an alternative way to do this to solve this
problem in a way that works on all operating systems. It's mainly a developer
problem as the permissions are set using the packaging scripts for deployments.
A check if mkdir and cp exists before doing the copy should work i think, but
maybe there is an ant task that will take care of the permissions on unix based
systems. Or maybe explicitly call bash instead of depending to the os to
execute the script. I don't have much time this weekend, but I'm willing to see
if I can find a solution next week.
Cheers,
Hugo
-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: zaterdag 2 maart 2013 20:01
To: cloudstack-dev@incubator.apache.org
Cc: Hugo Trippaers (trip...@gmail.com)
Subject: Re: copying scripts in client/pom.xml
On Fri, Mar 01, 2013 at 03:20:38PM -0800, Frank Zhang wrote:
Hi Hugo:
I noticed your recent change as below. It will cause bug
https://issues.apache.org/jira/browse/CLOUDSTACK-1304 that I have
fixed some days ago
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 271)
copy
todir=${basedir}/target/generated-webapp/WEB-INF/classes/scripts
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 272)
fileset dir=${basedir}/../scripts /
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 273)
/copy
my fixes basically does:
exec executable=cp
arg value=-r /
arg value=${basedir}/../scripts /
arg value=${basedir}/target/generated-webapp/WEB-
INF/classes/scripts /
/exec
Is there any special reason you changed it back? Thank
you
Frank / Hugo - Should we reopen CLOUDSTACK-1304?
I'd also suggest that the description of the bug makes it a bit higher than
the
Major designation (i.e.: we should fix it in 4.1).
Re: copying scripts in client/pom.xml
On Sat, Mar 02, 2013 at 07:34:44PM +, Hugo Trippaers wrote:
Hey Frank,
I reopened the ticket with the following comment:
I reverted this commit because it breaks the system for developers who use an
operating system that has no cp or mkdir command (the mkdir was later added
by Rohit)
I did not notice the original issue because the executable bit is not an
issue on windows systems. We should find an alternative way to do this to
solve this problem in a way that works on all operating systems. It's mainly
a developer problem as the permissions are set using the packaging scripts
for deployments.
A check if mkdir and cp exists before doing the copy should work i think, but
maybe there is an ant task that will take care of the permissions on unix
based systems. Or maybe explicitly call bash instead of depending to the os
to execute the script. I don't have much time this weekend, but I'm willing
to see if I can find a solution next week.
OK - based on that description, this is a nice to fix for 4.1. True?
If the fix is low risk, we should consider bringing it into 4.1 anyway
(given the pain that a dev will have without a fix).
Cheers,
Hugo
-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: zaterdag 2 maart 2013 20:01
To: cloudstack-dev@incubator.apache.org
Cc: Hugo Trippaers (trip...@gmail.com)
Subject: Re: copying scripts in client/pom.xml
On Fri, Mar 01, 2013 at 03:20:38PM -0800, Frank Zhang wrote:
Hi Hugo:
I noticed your recent change as below. It will cause bug
https://issues.apache.org/jira/browse/CLOUDSTACK-1304 that I have
fixed some days ago
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 271)
copy
todir=${basedir}/target/generated-webapp/WEB-INF/classes/scripts
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 272)
fileset dir=${basedir}/../scripts /
be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 273)
/copy
my fixes basically does:
exec executable=cp
arg value=-r /
arg value=${basedir}/../scripts /
arg value=${basedir}/target/generated-webapp/WEB-
INF/classes/scripts /
/exec
Is there any special reason you changed it back? Thank
you
Frank / Hugo - Should we reopen CLOUDSTACK-1304?
I'd also suggest that the description of the bug makes it a bit higher than
the
Major designation (i.e.: we should fix it in 4.1).
Re: [ACS41][Patch Request] agent.properties from RPM is blocking proper agent setup
I went back and looked at the wiki, and I think I misunderstood one of the sections. It shows examples of things to put into the commit, Reviewed-by:,Signed-off-by:,Reported-by:, and then below that, CLOUDSTACK-bug-id:, Maven:, Doc:, etc. It says the latter group should be prefixes, which I apparently thought meant begin your lines with these. Most people seem to be using those as the beginning of the actual commit message, so I'll conform to that. On Sat, Mar 2, 2013 at 12:34 PM, Chip Childers chip.child...@sungard.com wrote: On Sat, Mar 02, 2013 at 12:28:55PM -0700, Marcus Sorensen wrote: The bug was created a few hours before the commit. I didn't even know I'd end up fixing it. I thought we had standardized on a BUG-ID: header in commits, way back in October or so when Rohit was asking for better commit messages. We even created a pre-commit hook people could use to prepopulate their commits with common fields. You're totally right! For some reason, I didn't see the bug ID. Blind to the exact info I was looking for I guess!
[jira] [Updated] (CLOUDSTACK-1461) Ipv6 - From a Vm that that is part of 2 networks, non default network router's details should not get programmed in the DNS entries of the guest VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-1461: Summary: Ipv6 - From a Vm that that is part of 2 networks, non default network router's details should not get programmed in the DNS entries of the guest VM. (was: Ipv6 - From a Vm that that is part of 2 networks, DNS entries of the non default network router should not get programmed in the guest VM. ) Ipv6 - From a Vm that that is part of 2 networks, non default network router's details should not get programmed in the DNS entries of the guest VM. -- Key: CLOUDSTACK-1461 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1461 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sangeetha Hariharan Assignee: Sheng Yang Ipv6 - From a Vm that that is part of 2 networks, Name resolution fails for Vms that are part of non default network fails Steps to reproduce the problem: Create a dual stack network ,N1 Create a dual stack network, N2. Deploy a VM - vm1 in N1 and N2. Deploy a VM - vm2 in N2. From vm1 , try to reach vm2 using the vm-name. DNS name resolution fails. /etc/resolv.conf does not have the IPV4 address of the router that belongs to non default networks. It does have the IPV6 address of the router that belongs to non default networks.But seems like it is not being used for name resolution. sangeetha@ubuntu-123:~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.223.137.66 nameserver fc00:3:1371::6a19:fed0:1932:3626 nameserver fc00:3:1370::a659:ce38:85fe:a024 search hello1371 hello1370 sangeetha@ubuntu-123:~$ sangeetha@ubuntu-123:~$ ifconfig eth0 Link encap:Ethernet HWaddr 06:7c:3c:00:00:4e inet addr:10.223.137.71 Bcast:10.223.137.127 Mask:255.255.255.192 inet6 addr: fc00:3:1371:0::::/64 Scope:Global inet6 addr: fe80::47c:3cff:fe00:4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:556 errors:0 dropped:0 overruns:0 frame:0 TX packets:331 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:49282 (49.2 KB) TX bytes:33852 (33.8 KB) eth1 Link encap:Ethernet HWaddr 06:22:cc:00:00:1d inet addr:10.223.137.12 Bcast:10.223.137.31 Mask:255.255.255.224 inet6 addr: fc00:3:1370:0:81b8:c352:31e1:69e4/64 Scope:Global inet6 addr: fe80::422:ccff:fe00:1d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2003 errors:0 dropped:0 overruns:0 frame:0 TX packets:1634 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:188275 (188.2 KB) TX bytes:223403 (223.4 KB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4038 (4.0 KB) TX bytes:4038 (4.0 KB) sangeetha@ubuntu-123:~$ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1304) mvn -pl :cloud-client-ui jetty:run strips permission of files in script/
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591495#comment-13591495
]
ASF subversion and git services commented on CLOUDSTACK-1304:
-
Commit ce6f8aafd2aa717c034df6b562cc204edd5e5434 in branch refs/heads/4.1 from
Hugo Trippaers trip...@gmail.com
[ https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;h=ce6f8aa ]
CLOUDSTACK-1304 Set permissions using the chmod ant task
mvn -pl :cloud-client-ui jetty:run strips permission of files in script/
---
Key: CLOUDSTACK-1304
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1304
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0
Reporter: frank zhang
Assignee: frank zhang
Fix For: 4.1.0
mvn -pl :cloud-client-ui jetty:run calls ant task copy to copy files
under script/ to ${basedir}/target/generated-webapp/WEB-INF/classes/scripts
it will strip all permission on files to default system permission which
erases execution bit on script. the reason is
Unix Note: File permissions are not retained when files are copied; they end
up with the default UMASK permissions instead. This is caused by the lack of
any means to query or set file permissions in the current Java runtimes. If
you need a permission-preserving copy function, use exec executable=cp ...
instead.
http://ant.apache.org/manual/Tasks/copy.html
this issue will prevent mgmt server executes any shell script due to lacking
of execution permission on script
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: problem with current master and vmware for creating instances
Thanks a lot. The problem was the compilation command. I was using mvn install
-Dnonoss maybe because i've read a lot of pages describing the build process
and I stopped on one that has worked the first time ;-)
Julien Garet
- Mail original -
De: Min Chen min.c...@citrix.com
À: cloudstack-dev@incubator.apache.org
Envoyé: Samedi 2 Mars 2013 01:55:52
Objet: Re: problem with current master and vmware for creating
instances
Are you talking about systemvm.iso or systemvm template? I am also
using
Burbank system vm template for my testing. But systemvm.iso needs to
be
rebuilt by running mvn clean install -P developer,systemvm
-Dnonoss.
Remember to clear your previous systemvm-4.2.0-SNAPSHOT.iso from your
secondary storage to avoid using any old code.
Thanks
-min
On 3/1/13 4:13 PM, Julien Garet julien.ga...@inria.fr wrote:
That's strange, i've been using this branch. Do system VMs remain
the
same ? I am using the burbank system VMs, are they still OK ?
Julien Garet
Le 2 mars 2013 à 00:14, Min Chen min.c...@citrix.com a écrit :
Yes, systemvm.log is not activated on master, I have enabled it on
vim51_win8 branch.
On vim51_win8, I used to encounter this certificate issue, then
fixed it
with this commit 525fe14c25877aeb0c49a6ca8aa9d18f62ff97e2. In
running
VMWare from source, remember that you need to manually run chmod
+x to
make injectkeys.sh become executables, other systemvm.iso will not
have
correct keys.
Thanks
-min
On 3/1/13 1:49 PM, Julien Garet julien.ga...@inria.fr wrote:
systemvm.log is not activated by default, documentation is
missing on
how
to activate it.
The main problem is linked to certificate validation
2013-03-01 21:15:40,157 ERROR
[storage.resource.VmwareSecondaryStorageResourceHandler]
(agentRequest-Handler-1:) Unexpected exception
com.sun.xml.internal.ws.client.ClientTransportException: HTTP
transport
error: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to
find valid certification path to requested target
com.sun.xml.internal.ws.client.ClientTransportException: HTTP
transport
error: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to
find valid certification path to requested target
and later
2013-03-01 21:15:40,159 WARN
[storage.resource.VmwareSecondaryStorageResourceHandler]
(agentRequest-Handler-1:) Unable to retrive host network
information
due
to exception java.lang.NullPointerException, host:
HostSystem-host-132
2013-03-01 21:15:40,159 ERROR
[vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:) Unable to execute
PrimaryStorageDownloadCommand
due to exception
java.lang.NullPointerException
Is that validation for vcenter server connection ?
Julien Garet
- Mail original -
De: Min Chen min.c...@citrix.com
À: cloudstack-dev@incubator.apache.org
Cc: cloudstack-dev@incubator.apache.org
Envoyé: Vendredi 1 Mars 2013 20:15:31
Objet: Re: problem with current master and vmware for creating
instances
This command is executed from SSVM, so you need to log into SSVM
to
find the systemvm.log from /var/log/cloud to see what exception
you
got.
Thanks
-min
Sent from my iPhone
On Mar 1, 2013, at 4:58 AM, Julien Garet
julien.ga...@inria.fr
wrote:
I've found something, I think. The template was refered in the
template_spool_ref with all NULL values.
Removing this entry make it trying to download the template.
But it
does not complete due to errors :
013-03-01 13:48:27,559 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-1:job-35) Checking if we need to prepare 1
volumes
for VM[User|e6fbcefb-9098-4eab-8f6c-0b8370907edd]
2013-03-01 13:48:27,722 DEBUG
[cloud.template.TemplateManagerImpl]
(Job-Executor-1:job-35) Downloading 7 via 1
2013-03-01 13:48:27,732 DEBUG [agent.transport.Request]
(Job-Executor-1:job-35) Seq 3-1058930794: Sending { Cmd ,
MgmtId:
345042876358, via: 3, Ver: v1, Flags: 100111,
[{storage.PrimaryStorageDownloadCommand:{
localPath:/mnt/cc08b902-cbe8-3b8d-a987-3167edafafc7,poolUuid:cc0
8b
902-cbe8-3b8d-a987-3167edafafc7,poolId:200,primaryPool:{id:200,
uu
id:cc08b902-cbe8-3b8d-a987-3167edafafc7,host:172.21.4.2,pa
th:/data/testosx,port:2049,type:NetworkFilesystem},secondaryS
to
rageUrl:nfs://172.21.4.3/containers/testosx,primaryStorageUrl:nfs
:/
/172.21.4.2/data/testosx,url:nfs://172.21.4.3/containers/testo
sx/template/tmpl//1/7//caf8bd2a-d967-3094-95aa-2d9d1764f9a8.ova,forma
t
:OVA,accountId:1,name:centos53-x64,wait:10800}}]
}
2013-03-01 13:48:28,865 DEBUG
[agent.manager.DirectAgentAttache]
(DirectAgent-49:null) Ping
injectkeys.sh wrong permissions after maven build
I've been encountering this error some times ago, could it be solved, in the source tree there are exec permissions but after Maven build , perms ars set wrong, without exec flag. Cannot run program /root/code-browse/incubator-cloudstack/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh: error=13, Permission denied
RE: injectkeys.sh wrong permissions after maven build
Hi , In case you are on the latest master build , this problem might be because of this commit not being there in the master - http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/e219ef95 . Though this is there in asf/4.1 . Perhaps you could try to apply those set of code changes on your repo and try building using Maven again. Thanks, Pranav -Original Message- From: Sinisa Denic [mailto:sde...@peacebellservers.com] Sent: Sunday, March 03, 2013 1:33 AM To: cloudstack-dev@incubator.apache.org Subject: injectkeys.sh wrong permissions after maven build I've been encountering this error some times ago, could it be solved, in the source tree there are exec permissions but after Maven build , perms ars set wrong, without exec flag. Cannot run program /root/code-browse/incubator-cloudstack/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh: error=13, Permission denied
Re: New PPMC Member: Sebastien Goasguen
Grats! On 1 March 2013 22:13, Chip Childers chip.child...@sungard.com wrote: Hi folks The Podling Project Management Committee (PPMC) for Apache CloudStack has asked Sebastien to become a member of the PPMC and we are pleased to announce that he has accepted. Please join me in congratulating Sebastien! Regards, --Chip on behalf of the CloudStack PPMC -- NS
Re: New PPMC member: Marcus Sorenson
Grats! On 1 March 2013 17:27, David Nalley da...@gnsa.us wrote: Hi folks The Podling Project Management Committee (PPMC) for Apache CloudStack has asked Marcus to become a member of the PPMC and we are pleased to announce that he has accepted. Please join me in congratulating Marcus! (and apologies on the delay in getting this out in a timely manner) Regards, --David on behalf of the CloudStack PPMC -- NS
Jenkins builds
Hi, could someone check on your Jenkins builds? A couple of them look like they could be stuck (run time any previous successful run). Thanks! Billie
Re: Review Request: 4.1 deb packaging tomcat fixes
On March 2, 2013, 4:35 p.m., Wido den Hollander wrote: Seems partially right. This is against the 4.1 branch, correct? Since the logfile fixes are already in master. Best practice is to check master first and cherry pick stuff to 4.1 Yes, this is against the 4.1 branch. cherry-pick from master sounds like a better way to do it. I'll update the patch - Noa --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/#review17302 --- On March 2, 2013, 1:55 p.m., Noa Resare wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 1:55 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules d537d86 packaging/debian/replace.properties d891e79 Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: Review Request: 4.1 deb packaging tomcat fixes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 11:34 p.m.) Review request for cloudstack and Wido den Hollander. Changes --- The updated diff is against master. Let's get it in there first, and cherry-pick onto 4.1 after careful consideration. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs (updated) - debian/rules ba9056e packaging/debian/replace.properties fee1def Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: Review Request: 4.1 deb packaging tomcat fixes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 11:34 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules ba9056e packaging/debian/replace.properties fee1def Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: Review Request: 4.1 deb packaging tomcat fixes
Let me know when you guys are ready to move it to 4.1. Thanks! On Mar 2, 2013, at 6:34 PM, Noa Resare n...@resare.com wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 11:34 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules ba9056e packaging/debian/replace.properties fee1def Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
RE: Failed to addCluster with latest master code
From: Min Chen Sent: 02 March 2013 07:34 To: cloudstack-dev@incubator.apache.org Cc: Sateesh Chodapuneedi Subject: Failed to addCluster with latest master code Hi there, In preparing merging my feature branch vim51_win8 to master, I rebased with latest master code, then my testing immediately failed at addCluster with the following stack trace: 2013-03-01 17:34:18,953 DEBUG [cloud.network.NetworkModelImpl] (552681680@qtp-144013098-6:null) Failed to retrieve the default label for public traffic.zone: 1 hypervisor: VMware due to: Unable to find the default physical network with traffic=Public in zone id=1. 2013-03-01 17:34:19,305 ERROR [cloud.api.ApiServer] (552681680@qtp- 144013098-6:null) unhandled exception executing api command: addCluster java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:571) at java.util.ArrayList.get(ArrayList.java:349) at com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDisc overer.java:214) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.i nvokeJoinpoint(Cglib2AopProxy.java:689) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl ectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proce ed(MethodInvocationProceedingJoinPoint.java:80) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionC ontextBuilder.java:54) at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) Min, Fixed this issue. Can you please pull latest master and re-try?
