Excerpts from Saverio Proto's message of 2018-01-24 22:18:39 +0100:
> > 3.34.0 is a queens series release, which makes it more likely that more
> > other dependencies would need to be updated. Even backporting the
> > changes to the Ocata branch and releasing it from there would require
> >
> 3.34.0 is a queens series release, which makes it more likely that more
> other dependencies would need to be updated. Even backporting the
> changes to the Ocata branch and releasing it from there would require
> updating several other libraries.
>
That is what I was fearing. Consider that
Excerpts from Saverio Proto's message of 2018-01-23 10:21:37 +0100:
> Hello Doug,
>
> I have run the script:
> here is my output:
>
> http://paste.openstack.org/show/650913/
It looks like the logger returned by oslo.log does include the
values in the "extra" section but the others do not
Hello Doug,
I have run the script:
here is my output:
http://paste.openstack.org/show/650913/
At this point I have some questions. Can I upgrade just oslo.log library
keeping the rest of the stuff in Newton ?
The versions of oslo.log have a different numbering scheme than other
openstack
Excerpts from Saverio Proto's message of 2018-01-22 18:45:15 +0100:
> Hello Doug,
>
> in the extra session I see just {"project": "unknown", "version": "unknown"}
>
> here a full line from nova-api:
>
> {"thread_name": "MainThread", "extra": {"project": "unknown", "version":
> "unknown"},
Hello Doug,
in the extra session I see just {"project": "unknown", "version": "unknown"}
here a full line from nova-api:
{"thread_name": "MainThread", "extra": {"project": "unknown", "version":
"unknown"}, "process": 31142, "relative_created": 3459415335.4091644,
"module": "wsgi", "message":
Excerpts from Saverio Proto's message of 2018-01-21 18:09:03 +0100:
> Hello,
>
> I figured out a bug is already open since a long time :(
> https://bugs.launchpad.net/oslo.log/+bug/1564931
>
> And there is already a review:
> https://review.openstack.org/#/c/367514/
>
> it looks like the review
Hello,
I figured out a bug is already open since a long time :(
https://bugs.launchpad.net/oslo.log/+bug/1564931
And there is already a review:
https://review.openstack.org/#/c/367514/
it looks like the review was not merged, and it went to abandoned
because of no progress on it for long time.
Excerpts from Doug Hellmann's message of 2018-01-18 11:45:28 -0500:
> Excerpts from Saverio Proto's message of 2018-01-18 14:49:21 +0100:
> > Hello all,
> >
> > well this oslo.log library looks like a core thing that is used by
> > multiple projects. I feel scared hearing that bugs opened on that
Excerpts from Saverio Proto's message of 2018-01-18 14:49:21 +0100:
> Hello all,
>
> well this oslo.log library looks like a core thing that is used by
> multiple projects. I feel scared hearing that bugs opened on that
> project are probably just ignored.
>
> should I reach out to the current
Hello all,
well this oslo.log library looks like a core thing that is used by
multiple projects. I feel scared hearing that bugs opened on that
project are probably just ignored.
should I reach out to the current PTL of OSLO ?
A bug would be fine. I'm not sure how many people are keeping an eye on
oslo.log bugs at this point, so be realistic in when it might get looked at.
On 01/18/2018 03:06 AM, Saverio Proto wrote:
> Hello Sean,
> after the brief chat we had on IRC, do you think I should open a bug
> about this issue
Hello Sean,
after the brief chat we had on IRC, do you think I should open a bug
about this issue ?
thank you
Saverio
On 13.01.18 07:06, Saverio Proto wrote:
>> I don't think this is a configuration problem.
>>
>> Which version of the oslo.log library do you have installed?
>
> Hello Doug,
>
> I don't think this is a configuration problem.
>
> Which version of the oslo.log library do you have installed?
Hello Doug,
I use the Ubuntu packages, at the moment I have this version:
python-oslo.log 3.16.0-0ubuntu1~cloud0
thank you
Saverio
Excerpts from Saverio Proto's message of 2018-01-12 09:17:55 +0100:
> > Which service's logs are missing the request_id?
> >
> If I look at neutron-server logs with my current setup I get two files:
>
> neutron-server.log
> neutron-server.json
>
> the standard log file has in all neutron.wsgi
> Which service's logs are missing the request_id?
>
If I look at neutron-server logs with my current setup I get two files:
neutron-server.log
neutron-server.json
the standard log file has in all neutron.wsgi lines information like:
neutron.wsgi [req-4fda8017-50c7-40eb-9e7b-710e7fba0d01
Excerpts from Saverio Proto's message of 2018-01-11 15:23:46 +0100:
> Hello,
>
> we recently enabled the JSON logging to feed a Kibana dashboard and look
> at the logs with modern tooling.
>
> however it looks like in our Openstack Newton deployment that some
> information in the JSON files is
Hello,
we recently enabled the JSON logging to feed a Kibana dashboard and look
at the logs with modern tooling.
however it looks like in our Openstack Newton deployment that some
information in the JSON files is missing.
most important missing bit is the request-id, that we use to track an
18 matches
Mail list logo
