On Wed, 2005-05-04 at 00:40 -0400, seth vidal wrote:
I've been doing a lot of tests today and I have some good news to
1. the xml-rpc communication is working pretty well. We can spawn builds
out to different hosts than the queuer and get feedback on what broke in
the build and/or why.
2. I've cleaned up the code and on my set of 2 systems (x86_64 and ppc)
I can build for all 3 architectures w/o having to manually run anything.
A couple of comments, some of which I'd even be willing to do the work
1) CVS/tobuild - Could this code be separated into an XML-RPC client?
So you'd have the Queuer be an XMLRPC server, and clients would connect
to it and feed it build jobs. For Aurora at least, we're probably not
going to have CVS of this type, and "tobuild" seems somewhat cumbersome.
I'd like to build a client that parses the output of Beehive emails and
queues a build (so that whenever something gets built internally at Red
Hat, it could get built into an Aurora build system)
There would be some type of authentication so the Queuer might only
accept connections from a certain host[s], eventually by SSL certificate
or something once that code gets done.
2) Config info - Man that's spread around a lot... Anyway, what's the
suggested configuration tool to use? I don't really like ConfigParser
all that much, but I don't want to do something else that people don't
like either. How about a simple "config.py" file that contains the
configuration as dict entries or something, and then the source would
use "config.get('localarch')"? Fairly simple, but suggestions
3) Could you explain a bit about the flow? The client/server separation
isn't extremely clear currently, such that the server includes the
builder code as well and calls some of it. Which scripts do you launch
on which machines? With which arguments? Could we separate the
server/queuer code from the XMLRPC/builder bits explicitly?
let me know what you think, even if I've wasted my time.
Certainly not wasted...