* .../logs/htmlify-screen-log.py: fileinput.input is a global attempting
to update it when it is already active causes problems. Instead create
dinstinct FileInput objects for iterating over files to avoid problems
with globals.
Change-Id: I6ac585e55c918b9bcdb188d347049cbb3abb4125
The 404 handler that previously existed didn't actually handle the
file not found case, because we hit it too late in the generator,
so all control was over in Apache. In order to deal with this
instead try to open and close the file early, to trigger the
exception before we get to the generator. This opens us up to a
small race, which we should never see on a real system. And also
let's us keep the generator approach which we need from a memory
perspective on the server.
Also ensure that we are only handling the non-query string part
of path info when we are trying to find a file, otherwise query
strings make everything 404.
And lastly, give us an out if we want to make a web browser get
the text version instead of the html version via passing
?content-type=text/plain on the query string. Some logs like
nova-api are so large (35MB of html) that some browsers on some
OSes completely fall over dealing with them. This will let those
users get around it if it's a problem.
Change-Id: I7383deb95dcbc097aa6c1053dc9bb5a8de04cf26
change the date link to something human creatable (the uri escapes
got obtuse quickly). Also change it to something which is a valid
css class name so that we could highlight the lines later. This
required some changes to span parsing to inject the additional
css class.
Finally add a couple of fixups suggested by clarkb and fungi on
the last round. This should be ready for main log server.
Change-Id: Ia5111873ee60c174a5c7ddc479fa0c63ead9d97d
ensure that path of the file we're going to open is actually
inside our log root. If not return a 400.
escape dates in the regex so they are easier to pass around,
unencoded spaces kind of suck for that.
catch the possible IOError of openning a file that doesn't exist,
be nice and give people a 404 in that case.
move the content negotiation into a function, for readability
Change-Id: I334e1ac0419cd140c6af35c78634a2d7c05dcf01
this adds a wsgi application which processes all the txt.gz log
files and htmlifies them on the fly before sending them to the
user. It uses content negotiation to only do this if the client
says it Accepts text/html, otherwise it just dumps them back out
as text/plain.
In either case the content is compressed with mod_deflate, which
provides a 15x-20x bandwidth savings vs. if we left it
uncompressed on the wire.
Should get more testing before general deployment, but this is
getting close to the approach I think we want to use.
This enables the functionality on a new logs-dev.openstack.org
vhost so that we can do live testing that this works before
switching over the main site to it.
Change-Id: I12a06c4b55be05fb8060b76f5aea9ebc801c0537
