On Wed, Feb 13, 2013 at 5:58 PM, Dave Cahill <dcah...@midokura.com> wrote: >>> logging for cloudstack-agent seems to work if I do 'mv >>> /etc/cloudstack/agent/log4j-cloud.xml >>> /etc/cloudstack/agent/log4j.xml'. Not sure what's going on there at >>> the moment, not familiar with log4j... anyone? > > ^ Thanks a million for this hint Marcus, worked great for me. Quite a bit > of logging weirdness in the current master, hope it gets fixed soon.
No problem. It was just a hunch, I have a knack for trying random crap until I find something that works. It's a lot easier to troubleshoot things when they log :-) > > On Thu, Feb 14, 2013 at 8:47 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > >> CLOUDSTACK-1267 >> >> On Wed, Feb 13, 2013 at 4:36 PM, Alex Huang <alex.hu...@citrix.com> wrote: >> > Marcus, >> > >> > Please file a bug and assign it to Kelven. This looks like something >> lost during the Spring transition because log4j was something >> ComponentLocator took care of previously. >> > >> > --Alex >> > >> >> -----Original Message----- >> >> From: Marcus Sorensen [mailto:shadow...@gmail.com] >> >> Sent: Wednesday, February 13, 2013 3:34 PM >> >> To: Sailaja Mada >> >> Cc: Kelven Yang; Alex Huang; cloudstack-dev@incubator.apache.org >> >> Subject: Re: [ACS41][QA]Issues observed with 4.1 >> >> >> >> logging for cloudstack-agent seems to work if I do 'mv >> >> /etc/cloudstack/agent/log4j-cloud.xml >> >> /etc/cloudstack/agent/log4j.xml'. Not sure what's going on there at >> >> the moment, not familiar with log4j... anyone? >> >> >> >> On Tue, Feb 5, 2013 at 10:59 PM, Marcus Sorensen <shadow...@gmail.com> >> >> wrote: >> >> > Ok. Mine is CLOUDSTACK-1168. I've marked mine as a duplicate, it's got >> >> > the link to the patch and an explanation of what's going on. >> >> > >> >> > On Tue, Feb 5, 2013 at 10:52 PM, Sailaja Mada < >> sailaja.m...@citrix.com> >> >> wrote: >> >> >> Hi Marcus, >> >> >> >> >> >> I have opened a ticket for NPE issue while creating firewall >> yesterday @ >> >> CLOUDSTACK-1163- Failed with NPE while creating firewall rule >> >> >> >> >> >> Thanks, >> >> >> Sailaja.M >> >> >> >> >> >> -----Original Message----- >> >> >> From: Marcus Sorensen [mailto:shadow...@gmail.com] >> >> >> Sent: Wednesday, February 06, 2013 11:17 AM >> >> >> To: Kelven Yang >> >> >> Cc: Alex Huang; cloudstack-dev@incubator.apache.org >> >> >> Subject: Re: [ACS41][QA]Issues observed with 4.1 >> >> >> >> >> >> I opened a case for #5. I also supplied a patch on reviewboard for >> it, which >> >> I'll apply if I don't get any feedback. It looks like >> createFirewallRule got split >> >> into createIngressFirewallRule and createEgressFirewallRule, and they >> now >> >> call a function that has returned null since before 4.0 >> >> >> >> >> >> #6 I've got another (which I've also created a case for, but since I >> think it >> >> might be related to spring or a very recent commit I'm bringing it up >> here). >> >> ConsoleProxy doesn't seem to work, I see this in the cloud log on the >> system >> >> vm: >> >> >> >> >> >> java -Djavax.net.ssl.trustStore=./certs/realhostip.keystore -Xmx512m >> - >> >> 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=consoleproxy >> >> >> host=172.17.10.10 port=8250 name=v-10-VM premium=true zone=1 >> >> pod=1 >> >> >> guid=Proxy.10 proxy_vm=10 disable_rp_filter=true >> >> >> eth2ip=192.168.100.106 eth2mask=255.255.255.0 gateway=192.168.100.1 >> >> >> eth0ip=169.254.0.119 eth0mask=255.255.0.0 eth1ip=172.17.10.104 >> >> >> eth1mask=255.255.255.0 mgmtcidr=192.168.100.0/24 localgw=172.17.10.1 >> >> >> internaldns1=8.8.4.4 dns1=8.8.8.8 >> >> >> 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: Instantiation excetion when loading resource: >> >> >> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource due to: >> >> >> java.lang.InstantiationException >> >> >> >> >> >> #7 Also the KVM agent doesn't seem to be logging anymore, probably >> >> something related to the 'No appenders could be found for logger' >> >> >> >> >> >> On Tue, Feb 5, 2013 at 10:33 PM, Kelven Yang <kelven.y...@citrix.com >> > >> >> wrote: >> >> >>> Sure. >> >> >>> >> >> >>> I tested in my local setup, you can actually use -Xmx512m settings >> to >> >> >>> run it. I'll look at the memory footprint issue together with the an >> >> >>> improvement effort to speed up management server startup time. With >> >> >>> Spring auto-component-scan turned on in a global scope, in a huge >> >> >>> system like CloudStack, it is just taking too long to start it up. >> >> >>> >> >> >>> Kelven >> >> >>> >> >> >>> On 2/5/13 9:19 PM, "Alex Huang" <alex.hu...@citrix.com> wrote: >> >> >>> >> >> >>>>Kelven, >> >> >>>> >> >> >>>>This needs to be a priority. Spring with just aop and di shouldn't >> be >> >> >>>>that huge. Something is wrong here. >> >> >>>> >> >> >>>>--Alex >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: Kelven Yang [mailto:kelven.y...@citrix.com] >> >> >>>>> Sent: Monday, February 04, 2013 5:57 PM >> >> >>>>> To: cloudstack-dev@incubator.apache.org >> >> >>>>> Subject: Re: [ACS41][QA]Issues observed with 4.1 >> >> >>>>> >> >> >>>>> Spring jars add up to make it cross the threshold line. I'm not >> sure >> >> >>>>>how much it has added, there are some tuning work to find a good >> >> >>>>>number here. >> >> >>>>> >> >> >>>>> Kelven >> >> >>>>> >> >> >>>>> >> >> >>>>> On 2/4/13 5:42 PM, "Chiradeep Vittal" < >> chiradeep.vit...@citrix.com> >> >> >>>>>wrote: >> >> >>>>> >> >> >>>>> >Kelven, what is the reason for the huge increase in required >> memory? >> >> >>>>> > >> >> >>>>> >On 2/4/13 5:22 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: >> >> >>>>> > >> >> >>>>> >>The JVM memory setting I gave after Javelin merge may be too >> >> >>>>>aggressive >> >> >>>>> >>if >> >> >>>>> >>you are running management server inside a VM. >> >> >>>>> >>-XX:MaxPermSize=512m >> >> >>>>> is >> >> >>>>> >>for >> >> >>>>> >>the fact that we have so many java classes (it might work in >> 256m >> >> >>>>> >>configuration I think) and -Xmx2g is for the total heap (2G), >> >> >>>>> >>almost >> >> >>>>>the >> >> >>>>> >>maximum for a 32-bit process, if you are running inside a VM and >> >> >>>>> >>don't have much management server load, you may try out with 1G >> >> of >> >> >>>>> >>heap >> >> >>>>>size. >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >>Kelven >> >> >>>>> >> >> >> >>>>> >>On 2/4/13 3:44 PM, "Ryan Dietrich" <r...@betterservers.com> >> >> wrote: >> >> >>>>> >> >> >> >>>>> >>>Actually, the build reported success with no errors! I ended >> up >> >> >>>>> >>>blowing >> >> >>>>> >>>away my entire cloudstack vm and started over. Things seem >> to >> >> be >> >> >>>>> >>>working now. >> >> >>>>> >>>I actually run the management server ON devcloud itself, so the >> >> >>>>> >>>new memory requirements required me to up my settings (i.e.: >> >> >>>>> >>>export MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx2g") >> >> >>>>> >>> >> >> >>>>> >>>/boot/grub/grub.cfg >> >> >>>>> >>> >> >> >>>>> >>>I upped my xen "dom0_mem" so I could get a little more base >> >> memory. >> >> >>>>>I >> >> >>>>> >>>was swapping quite badly when trying to launch jetty, and got >> >> >>>>> >>>memory errors along the way. >> >> >>>>> >>> >> >> >>>>> >>>-Ryan Dietrich >> >> >>>>> >>> >> >> >>>>> >>>On Feb 4, 2013, at 3:00 PM, Kelven Yang < >> kelven.y...@citrix.com> >> >> >>>>>wrote: >> >> >>>>> >>> >> >> >>>>> >>>> It looks like your first command was actually failed to >> execute? >> >> >>>>> >>>> com.cloud.upgrade.DatabaseCreator is packaged in the artifact >> >> >>>>> >>>> from >> >> >>>>> the >> >> >>>>> >>>> first command. >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> Kelven >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> On 2/4/13 9:20 AM, "Ryan Dietrich" <r...@betterservers.com> >> >> wrote: >> >> >>>>> >>>> >> >> >>>>> >>>>> After a pull on the master branch, I am unable to deploy the >> >> >>>>> >>>>>database. >> >> >>>>> >>>>> >> >> >>>>> >>>>> I ran: >> >> >>>>> >>>>> mvn -P developer,systemvm clean install >> >> >>>>> >>>>> Then: >> >> >>>>> >>>>> mvn -P developer -pl developer,tools/devcloud -Ddeploydb >> I >> >> >>>>> >>>>>got: >> >> >>>>> >>>>> java.lang.ClassNotFoundException: >> >> >>>>> >>>>>com.cloud.upgrade.DatabaseCreator >> >> >>>>> >>>>> >> >> >>>>> >>>>> >> >> >>>>> >>>>> On Feb 4, 2013, at 9:40 AM, Sailaja Mada >> >> >>>>> >>>>><sailaja.m...@citrix.com> >> >> >>>>> >>>>>wrote: >> >> >>>>> >>>>> >> >> >>>>> >>>>>> Hi, >> >> >>>>> >>>>>> >> >> >>>>> >>>>>> These are the observations with 4.1 master branch dev >> >> >>>>> >>>>>>environment today . >> >> >>>>> >>>>> >> >> >>>>> >>>> >> >> >>>>> >>> >> >> >>>>> >> >> >> >>>>> > >> >> >>>> >> >> >>> >>