Re: CS MS Logging Level

2015-01-09 Thread Daan Hoogland
to get back with my findings so far,

The method I mentioned will work be it not that we have an explicit
mention of log4j configuration in our web.xml. It states that
'log4j-cloud.xml' should be searched on the classpath. I deleted the
extraneous file(s) from the hyperv plugin. This seems to solve the
problem. There are several other ways of loading the configuration
file in cloudstack. I haven't begun to consider consolidating them as
this is a multi process system and it does make sense. Point of
attention, though.


Daan

On Thu, Jan 8, 2015 at 3:41 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
 It seems I had thrown away another log4j conf to get this working:( I
 did a clean checkout and my trick isn't working anymore. keep you
 posted

 On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski
 mike.tutkow...@solidfire.com wrote:
 Great - thanks, Daan!

 On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:

 I got around looking at this (under peer pressure @SBP;) There is a
 property to maven jetty plugin:
   systemProperties
 systemProperty
   namelog4j.configuration/name
   value${project.build.directory}/log4j.xml/value !--
 or something like this --
 /systemProperty
   /systemProperties

 doing some final test before checking in. Not sure what changed but in
 jetty and when. It seems to pick the first or last on the class path
 or the lowest or highest hashed one without this set. dunno

 Daan

 On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  Anshul,
 
  The hyperv log4j configuration should not be used at all.
 
  On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
  anshul.gang...@citrix.com wrote:
  Daan,
 
  I am not seeing extraneous logs on my dev setup other than thread which
 is cleaning up expired async-jobs.
 
  You can safely change CONSOLE appender's threshold to INFO in hyperv
 plugin  if you think that is causing the problem.
  We will not lose much info which we want to show to user by this
 change. And in any case it will be available in vmops.log.
  CONSOLE appender's threshold is set to TRACE since the start of plugin.
 
  -Original Message-
  From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
  Sent: Tuesday, December 30, 2014 11:10 PM
  To: dev@cloudstack.apache.org
  Subject: Re: CS MS Logging Level
 
  No, vmops.log does not seem to be getting spammed...just the console.
 
  On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
 
  wrote:
 
  Mike,
 
  It doesn't spew to vmops.log anymore, right? It seems that the new
  jetty version interprets all the log4j/classpath differently and the
  one from the hyperv plugin takes precedence. I have been looking for a
  solution but haven't found one yet.
 
  On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
   Hi,
  
   Does anyone know if the logging level or something like that changed
   on
  the
   management server in 4.6?
  
   It seems like it's spewing out tons of information to the console
   these days.
  
   Thanks!
  
   --
   *Mike Tutkowski*
   *Senior CloudStack Developer, SolidFire Inc.*
   e: mike.tutkow...@solidfire.com
   o: 303.746.7302
   Advancing the way the world uses the cloud
   http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan
 
 
 
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan



 --
 Daan




 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the cloud
 http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan



-- 
Daan


Re: CS MS Logging Level

2015-01-09 Thread Mike Tutkowski
Awesome - thanks again, Daan!

On Fri, Jan 9, 2015 at 2:36 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 to get back with my findings so far,

 The method I mentioned will work be it not that we have an explicit
 mention of log4j configuration in our web.xml. It states that
 'log4j-cloud.xml' should be searched on the classpath. I deleted the
 extraneous file(s) from the hyperv plugin. This seems to solve the
 problem. There are several other ways of loading the configuration
 file in cloudstack. I haven't begun to consider consolidating them as
 this is a multi process system and it does make sense. Point of
 attention, though.


 Daan

 On Thu, Jan 8, 2015 at 3:41 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  It seems I had thrown away another log4j conf to get this working:( I
  did a clean checkout and my trick isn't working anymore. keep you
  posted
 
  On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
  Great - thanks, Daan!
 
  On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com
  wrote:
 
  I got around looking at this (under peer pressure @SBP;) There is a
  property to maven jetty plugin:
systemProperties
  systemProperty
namelog4j.configuration/name
value${project.build.directory}/log4j.xml/value !--
  or something like this --
  /systemProperty
/systemProperties
 
  doing some final test before checking in. Not sure what changed but in
  jetty and when. It seems to pick the first or last on the class path
  or the lowest or highest hashed one without this set. dunno
 
  Daan
 
  On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland 
 daan.hoogl...@gmail.com
  wrote:
   Anshul,
  
   The hyperv log4j configuration should not be used at all.
  
   On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
   anshul.gang...@citrix.com wrote:
   Daan,
  
   I am not seeing extraneous logs on my dev setup other than thread
 which
  is cleaning up expired async-jobs.
  
   You can safely change CONSOLE appender's threshold to INFO in hyperv
  plugin  if you think that is causing the problem.
   We will not lose much info which we want to show to user by this
  change. And in any case it will be available in vmops.log.
   CONSOLE appender's threshold is set to TRACE since the start of
 plugin.
  
   -Original Message-
   From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
   Sent: Tuesday, December 30, 2014 11:10 PM
   To: dev@cloudstack.apache.org
   Subject: Re: CS MS Logging Level
  
   No, vmops.log does not seem to be getting spammed...just the
 console.
  
   On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland 
 daan.hoogl...@gmail.com
  
   wrote:
  
   Mike,
  
   It doesn't spew to vmops.log anymore, right? It seems that the new
   jetty version interprets all the log4j/classpath differently and
 the
   one from the hyperv plugin takes precedence. I have been looking
 for a
   solution but haven't found one yet.
  
   On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
   mike.tutkow...@solidfire.com wrote:
Hi,
   
Does anyone know if the logging level or something like that
 changed
on
   the
management server in 4.6?
   
It seems like it's spewing out tons of information to the console
these days.
   
Thanks!
   
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*
  
  
  
   --
   Daan
  
  
  
  
   --
   *Mike Tutkowski*
   *Senior CloudStack Developer, SolidFire Inc.*
   e: mike.tutkow...@solidfire.com
   o: 303.746.7302
   Advancing the way the world uses the cloud
   http://solidfire.com/solution/overview/?video=play*™*
  
  
  
   --
   Daan
 
 
 
  --
  Daan
 
 
 
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan



 --
 Daan




-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*


Re: CS MS Logging Level

2015-01-08 Thread Daan Hoogland
It seems I had thrown away another log4j conf to get this working:( I
did a clean checkout and my trick isn't working anymore. keep you
posted

On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
 Great - thanks, Daan!

 On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:

 I got around looking at this (under peer pressure @SBP;) There is a
 property to maven jetty plugin:
   systemProperties
 systemProperty
   namelog4j.configuration/name
   value${project.build.directory}/log4j.xml/value !--
 or something like this --
 /systemProperty
   /systemProperties

 doing some final test before checking in. Not sure what changed but in
 jetty and when. It seems to pick the first or last on the class path
 or the lowest or highest hashed one without this set. dunno

 Daan

 On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  Anshul,
 
  The hyperv log4j configuration should not be used at all.
 
  On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
  anshul.gang...@citrix.com wrote:
  Daan,
 
  I am not seeing extraneous logs on my dev setup other than thread which
 is cleaning up expired async-jobs.
 
  You can safely change CONSOLE appender's threshold to INFO in hyperv
 plugin  if you think that is causing the problem.
  We will not lose much info which we want to show to user by this
 change. And in any case it will be available in vmops.log.
  CONSOLE appender's threshold is set to TRACE since the start of plugin.
 
  -Original Message-
  From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
  Sent: Tuesday, December 30, 2014 11:10 PM
  To: dev@cloudstack.apache.org
  Subject: Re: CS MS Logging Level
 
  No, vmops.log does not seem to be getting spammed...just the console.
 
  On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
 
  wrote:
 
  Mike,
 
  It doesn't spew to vmops.log anymore, right? It seems that the new
  jetty version interprets all the log4j/classpath differently and the
  one from the hyperv plugin takes precedence. I have been looking for a
  solution but haven't found one yet.
 
  On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
   Hi,
  
   Does anyone know if the logging level or something like that changed
   on
  the
   management server in 4.6?
  
   It seems like it's spewing out tons of information to the console
   these days.
  
   Thanks!
  
   --
   *Mike Tutkowski*
   *Senior CloudStack Developer, SolidFire Inc.*
   e: mike.tutkow...@solidfire.com
   o: 303.746.7302
   Advancing the way the world uses the cloud
   http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan
 
 
 
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan



 --
 Daan




 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the cloud
 http://solidfire.com/solution/overview/?video=play*™*



-- 
Daan


Re: CS MS Logging Level

2015-01-08 Thread Mike Tutkowski
Great - thanks, Daan!

On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 I got around looking at this (under peer pressure @SBP;) There is a
 property to maven jetty plugin:
   systemProperties
 systemProperty
   namelog4j.configuration/name
   value${project.build.directory}/log4j.xml/value !--
 or something like this --
 /systemProperty
   /systemProperties

 doing some final test before checking in. Not sure what changed but in
 jetty and when. It seems to pick the first or last on the class path
 or the lowest or highest hashed one without this set. dunno

 Daan

 On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  Anshul,
 
  The hyperv log4j configuration should not be used at all.
 
  On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
  anshul.gang...@citrix.com wrote:
  Daan,
 
  I am not seeing extraneous logs on my dev setup other than thread which
 is cleaning up expired async-jobs.
 
  You can safely change CONSOLE appender's threshold to INFO in hyperv
 plugin  if you think that is causing the problem.
  We will not lose much info which we want to show to user by this
 change. And in any case it will be available in vmops.log.
  CONSOLE appender's threshold is set to TRACE since the start of plugin.
 
  -Original Message-
  From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
  Sent: Tuesday, December 30, 2014 11:10 PM
  To: dev@cloudstack.apache.org
  Subject: Re: CS MS Logging Level
 
  No, vmops.log does not seem to be getting spammed...just the console.
 
  On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
 
  wrote:
 
  Mike,
 
  It doesn't spew to vmops.log anymore, right? It seems that the new
  jetty version interprets all the log4j/classpath differently and the
  one from the hyperv plugin takes precedence. I have been looking for a
  solution but haven't found one yet.
 
  On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
   Hi,
  
   Does anyone know if the logging level or something like that changed
   on
  the
   management server in 4.6?
  
   It seems like it's spewing out tons of information to the console
   these days.
  
   Thanks!
  
   --
   *Mike Tutkowski*
   *Senior CloudStack Developer, SolidFire Inc.*
   e: mike.tutkow...@solidfire.com
   o: 303.746.7302
   Advancing the way the world uses the cloud
   http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan
 
 
 
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*
 
 
 
  --
  Daan



 --
 Daan




-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*


Re: CS MS Logging Level

2015-01-08 Thread Daan Hoogland
I got around looking at this (under peer pressure @SBP;) There is a
property to maven jetty plugin:
  systemProperties
systemProperty
  namelog4j.configuration/name
  value${project.build.directory}/log4j.xml/value !--
or something like this --
/systemProperty
  /systemProperties

doing some final test before checking in. Not sure what changed but in
jetty and when. It seems to pick the first or last on the class path
or the lowest or highest hashed one without this set. dunno

Daan

On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
 Anshul,

 The hyperv log4j configuration should not be used at all.

 On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
 anshul.gang...@citrix.com wrote:
 Daan,

 I am not seeing extraneous logs on my dev setup other than thread which is 
 cleaning up expired async-jobs.

 You can safely change CONSOLE appender's threshold to INFO in hyperv plugin  
 if you think that is causing the problem.
 We will not lose much info which we want to show to user by this change. And 
 in any case it will be available in vmops.log.
 CONSOLE appender's threshold is set to TRACE since the start of plugin.

 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: Tuesday, December 30, 2014 11:10 PM
 To: dev@cloudstack.apache.org
 Subject: Re: CS MS Logging Level

 No, vmops.log does not seem to be getting spammed...just the console.

 On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:

 Mike,

 It doesn't spew to vmops.log anymore, right? It seems that the new
 jetty version interprets all the log4j/classpath differently and the
 one from the hyperv plugin takes precedence. I have been looking for a
 solution but haven't found one yet.

 On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
 mike.tutkow...@solidfire.com wrote:
  Hi,
 
  Does anyone know if the logging level or something like that changed
  on
 the
  management server in 4.6?
 
  It seems like it's spewing out tons of information to the console
  these days.
 
  Thanks!
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan




 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the cloud
 http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan



-- 
Daan


Re: CS MS Logging Level

2014-12-31 Thread Daan Hoogland
Anshul,

The hyperv log4j configuration should not be used at all.

On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
anshul.gang...@citrix.com wrote:
 Daan,

 I am not seeing extraneous logs on my dev setup other than thread which is 
 cleaning up expired async-jobs.

 You can safely change CONSOLE appender's threshold to INFO in hyperv plugin  
 if you think that is causing the problem.
 We will not lose much info which we want to show to user by this change. And 
 in any case it will be available in vmops.log.
 CONSOLE appender's threshold is set to TRACE since the start of plugin.

 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: Tuesday, December 30, 2014 11:10 PM
 To: dev@cloudstack.apache.org
 Subject: Re: CS MS Logging Level

 No, vmops.log does not seem to be getting spammed...just the console.

 On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:

 Mike,

 It doesn't spew to vmops.log anymore, right? It seems that the new
 jetty version interprets all the log4j/classpath differently and the
 one from the hyperv plugin takes precedence. I have been looking for a
 solution but haven't found one yet.

 On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
 mike.tutkow...@solidfire.com wrote:
  Hi,
 
  Does anyone know if the logging level or something like that changed
  on
 the
  management server in 4.6?
 
  It seems like it's spewing out tons of information to the console
  these days.
 
  Thanks!
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan




 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the cloud
 http://solidfire.com/solution/overview/?video=play*™*



-- 
Daan


Re: CS MS Logging Level

2014-12-30 Thread Daan Hoogland
Mike,

It doesn't spew to vmops.log anymore, right? It seems that the new
jetty version interprets all the log4j/classpath differently and the
one from the hyperv plugin takes precedence. I have been looking for a
solution but haven't found one yet.

On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
 Hi,

 Does anyone know if the logging level or something like that changed on the
 management server in 4.6?

 It seems like it's spewing out tons of information to the console these
 days.

 Thanks!

 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the cloud
 http://solidfire.com/solution/overview/?video=play*™*



-- 
Daan


Re: CS MS Logging Level

2014-12-30 Thread Mike Tutkowski
No, vmops.log does not seem to be getting spammed...just the console.

On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 Mike,

 It doesn't spew to vmops.log anymore, right? It seems that the new
 jetty version interprets all the log4j/classpath differently and the
 one from the hyperv plugin takes precedence. I have been looking for a
 solution but haven't found one yet.

 On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
 mike.tutkow...@solidfire.com wrote:
  Hi,
 
  Does anyone know if the logging level or something like that changed on
 the
  management server in 4.6?
 
  It seems like it's spewing out tons of information to the console these
  days.
 
  Thanks!
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan




-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*


RE: CS MS Logging Level

2014-12-30 Thread Anshul Gangwar
Daan,

I am not seeing extraneous logs on my dev setup other than thread which is 
cleaning up expired async-jobs.

You can safely change CONSOLE appender's threshold to INFO in hyperv plugin  if 
you think that is causing the problem.
We will not lose much info which we want to show to user by this change. And in 
any case it will be available in vmops.log.
CONSOLE appender's threshold is set to TRACE since the start of plugin.

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Tuesday, December 30, 2014 11:10 PM
To: dev@cloudstack.apache.org
Subject: Re: CS MS Logging Level

No, vmops.log does not seem to be getting spammed...just the console.

On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 Mike,

 It doesn't spew to vmops.log anymore, right? It seems that the new 
 jetty version interprets all the log4j/classpath differently and the 
 one from the hyperv plugin takes precedence. I have been looking for a 
 solution but haven't found one yet.

 On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski 
 mike.tutkow...@solidfire.com wrote:
  Hi,
 
  Does anyone know if the logging level or something like that changed 
  on
 the
  management server in 4.6?
 
  It seems like it's spewing out tons of information to the console 
  these days.
 
  Thanks!
 
  --
  *Mike Tutkowski*
  *Senior CloudStack Developer, SolidFire Inc.*
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud
  http://solidfire.com/solution/overview/?video=play*™*



 --
 Daan




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*


CS MS Logging Level

2014-12-29 Thread Mike Tutkowski
Hi,

Does anyone know if the logging level or something like that changed on the
management server in 4.6?

It seems like it's spewing out tons of information to the console these
days.

Thanks!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*