Updates:
Cc: mal.chromium [email protected] [email protected]
[email protected] [email protected] [email protected]
[email protected]
Comment #4 on issue 22839 by maruelatchromium: Create a new
StatusReceiverMultiService that sends BuildStatus to AppEngine
http://code.google.com/p/chromium/issues/detail?id=22839
Some side-effects that are interesting and didn't realize when first
writing this feature
request. I'm glad I left it on the shelf for a while, I think the concept
is better now.
Features:
- The buildbot masters really push data as it is generated (on each event)
to the GAE instance.
- The instance is *not* a status proxy. By using status push on the
masters, the instance should
precomputes a fair amount of data. In short, the instance *never* pulls
anything from buildbot.
- The instance can work as an aggregator. Multiple masters can connect to
it and the instance can
show an unified view independent on which master the build occured.
- BlobStore (which wasn't available in September '09) can be used to serve
most static content.
- Scales better.
- No DDoS issues.
- Removes most proxy maintenance. Less dedicated hardware.
- Perf analyzers, Gatekeeper, etc can be pushed to GAE. Much less server
maintenance.
- We can split masters really into a lot of small masters but that reduces
slave sharing
capability.
- Reduce CPU, I/O (which is significant) and memory usage on masters.
- Can be deployed progressively along side current status.
Downfalls:
- We loose much more status when GAE goes down. In fact, we actively loose
status data when GAE
datastore is read-only. Workarounds:
- The buildbots needs to keep unpushed data until pushed, even across
buildbot restarts. Fairly
trivial to pickle/unpickle as json.
- We can still keep a WebStatus when GAE is down to not be completely
blind but with splitted
masters, it's not as efficient.
- Fair amount of effort required. Not that much on buildbot's side, more
server's and UI rewrite
on GAE side.
- Needs custom backup solution.
- Needs to implement specific code for the "live" stdio links. Can be sent
to the current proxies
a build.chromium.org in the meantime until a nice solution is developed.
Once a stdio is closed,
it can be served from BlobStore instead.
Opinions?
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
