On Wed, Oct 23 2013, Sean Dague wrote:
> Goals - Short Term
> ===
> As much feedback as possible from both core projects and openstack deployers
> about the kinds of things that they believe we should be logging, and the
> kinds of levels they think those things should land at.
>
> Det
On 10/24/2013 11:46 AM, Brant Knudson wrote:
>
> On a previous project, I wrote a library that provided a command-line
> option to set the logging levels for different loggers. This was handy
> for developers and for support. An example translated to Keystone would
> be like
>
> keystone-all --lo
On a previous project, I wrote a library that provided a command-line
option to set the logging levels for different loggers. This was handy for
developers and for support. An example translated to Keystone would be like
keystone-all --logging=keystone.identity=DEBUG
Now the keystone.identity log
On 10/24/2013 11:00 AM, Sean Dague wrote:
> On 10/24/2013 10:05 AM, Dan Smith wrote:
>>> Example 1:
>>> ==
>>>
>>> n-conductor log in tempest/devstack -
>>> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
>>>
>>>
>>>
>>>
> If we had DEBUG and DEBUG2 levels, where one of them would only be seen
> at the higher debug level, would that be useful?
I'm fine with not seeing those for devstack runs, yeah.
--Dan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 10/24/2013 10:05 AM, Dan Smith wrote:
Example 1:
==
n-conductor log in tempest/devstack -
http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
Total log lines: 84076
Total non DEBUG lines: 61
Question: d
On Thu, Oct 24, 2013 at 3:24 PM, Lars Kellogg-Stedman wrote:
> On Thu, Oct 24, 2013 at 07:05:19AM -0700, Dan Smith wrote:
> > Some of them are not useful to me (but might be to others), like the
> > amqp channel lines. However, everything else has been pretty crucial at
> > one point or another wh
On Thu, Oct 24, 2013 at 07:05:19AM -0700, Dan Smith wrote:
> Some of them are not useful to me (but might be to others), like the
> amqp channel lines. However, everything else has been pretty crucial at
> one point or another when debugging issues that span between the two
> tightly-coupled servic
> Example 1:
> ==
>
> n-conductor log in tempest/devstack -
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
>
>
> Total log lines: 84076
> Total non DEBUG lines: 61
>
> Question: do we need more than 1 lev
I think harmonizing the log files is a great idea, when working on
elastic-recheck I spent a lot of time staring at log files and cursing at
how bad and non-uniform they are. I can only imagine what cloud operators
must think.
In addition to harmonizing the log levels, and makings sure we don't h
On 10/23/2013 03:35 PM, Robert Collins wrote:
On 24 October 2013 08:28, John Griffith wrote:
So I touched on this a bit in my earlier post but want to reiterate here and
maybe clarify a bit. I agree that cleaning up and standardizing the logs is
a good thing, and particularly removing unhandle
On Wed, Oct 23, 2013 at 3:26 PM, Robert Collins
wrote:
> On 24 October 2013 08:14, Dolph Mathews wrote:
> >
> > On Wed, Oct 23, 2013 at 1:20 PM, Sean Dague wrote:
>
> >
> > Deprecation warnings!
> >
> > Based on the approach we're taking in the patch below, we'll be able to
> > notate how immine
On 24 October 2013 08:28, John Griffith wrote:
> So I touched on this a bit in my earlier post but want to reiterate here and
> maybe clarify a bit. I agree that cleaning up and standardizing the logs is
> a good thing, and particularly removing unhandled exception messages would
> be good. What
On Wed, Oct 23, 2013 at 1:03 PM, Clark Boylan wrote:
> On Wed, Oct 23, 2013 at 11:20 AM, Sean Dague wrote:
> > One of the efforts that we're working on from the QA team is tooling that
> > ensures we aren't stack tracing into our test logs during normal tempest
> > runs. Random stack traces are s
On 24 October 2013 08:14, Dolph Mathews wrote:
>
> On Wed, Oct 23, 2013 at 1:20 PM, Sean Dague wrote:
>
> Deprecation warnings!
>
> Based on the approach we're taking in the patch below, we'll be able to
> notate how imminently a feature is facing deprecation. Right now, they're
> just landing i
On Wed, Oct 23, 2013 at 1:20 PM, Sean Dague wrote:
> One of the efforts that we're working on from the QA team is tooling that
> ensures we aren't stack tracing into our test logs during normal tempest
> runs. Random stack traces are scary to cloud admins consuming OpenStack
> logs, and exception
On Wed, Oct 23, 2013 at 11:20 AM, Sean Dague wrote:
> One of the efforts that we're working on from the QA team is tooling that
> ensures we aren't stack tracing into our test logs during normal tempest
> runs. Random stack traces are scary to cloud admins consuming OpenStack
> logs, and exception
One of the efforts that we're working on from the QA team is tooling
that ensures we aren't stack tracing into our test logs during normal
tempest runs. Random stack traces are scary to cloud admins consuming
OpenStack logs, and exceptions in the logs should really be exceptional
events (and in
18 matches
Mail list logo
