launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

We're working on <https://dev.launchpad.net/Projects/LiveBranches>
which is to try to get branch content a bit better integrated with the
main Launchpad UI, along the lines of
<https://dev.launchpad.net/ArchitectureGuide/ServicesRoadmap#loggerhead+(bazaar.launchpad.net+web+UI)>

We propose to do this by letting client javascript send requests that
get proxied through the front-end Apache to loggerhead, and then
changing Loggerhead to serve more machine-readable data: plain diffs
or file content, or json for things like file and revision metadata.
Obviously this needs a little care against xss.

Basically we would look at putting something like
<http://bazaar.launchpad.net/~jelmer/launchpad/apache-config-loggerhead/revision/13262>
into the front end Apache servers on banana and nutmeg.  mthaddon
thinks this is reasonable.  Probably it should be more restrictive
about what URLs are proxied.

If this approach is ok with Robert, I'd ask him to file an rt asking
for similar rewrite rules to be added, and (if necessary) firewall
rules to be changed to let those machines get to the loggerhead
server/s.  We can safely do this ahead of actually deploying code that
uses them.  We need to also block those URLs from robots.

Another separate but related thing would be for the web app front end
to do internal http requests to loggerhead, to get the same kind of
information, but to render it on the server side.  That probably means
giving Launchpad a concept for making an outgoing http request within
the dc, subject to a timeout, with some kind of tracking of when they
fail.  That seems generally useful in terms of the SOA plan, but
perhaps harder than doing it on the client, and maybe more likely to
make the page time out on the server side.  It would mean the page
will still work for robots and non-js browsers.   However, it would
mean that robots walking those pages of the main site will create load
on loggerhead, which could be substantial.

This may will likely create more load on codebrowse, but only
proportional to the amount that users are looking at it, so it seems
basically worthwhile.

Martin