continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <>
Subject Re: First Part of Distributed Builds
Date Tue, 13 Jan 2009 01:18:28 GMT
On Mon, Jan 12, 2009 at 7:38 AM, Marica Tan <> wrote:
> On Sat, Jan 10, 2009 at 12:52 AM, Wendy Smoak <> wrote:

> Nap is already working on the documentation. Wiki[1] needs to be updated.

DId you see I added some already?  I did the boring
menu-item-and-screenshot stuff, it's the "Understanding Distributed
Builds" page that needs your input.

> Slave is the same as a build agent. Change it to CONTINUUM_BUILD_AGENT?

It's a thought.  I liked the _HOME on the end, whatever it is.  But
it's more than just this, there's inconsistency on whether we use
'slave' or 'agent' throughout.  For example, it's Build Agents in the
master server's UI, but the agent's url is slave-xmlrpc.  I had
trouble writing the docs and this email, I'm not sure which to use.
FWIW I prefer "agent".

> Hmm... no it shouldn't [check out source code on the master]. Will fix this.

Thanks!  I'm curious how it knows whether there have been svn changes
if it happens to build on a different slave from last time...

>> What about security?  I didn't set up any users on the slave, can
>> anyone who knows the url add projects and execute builds?
> We don't use database in the slave so no redback. Will include documentation
> on how to secure communication through SSL, though not sure if it's enough
> for security.

Definintely needs more discussion; I don't think the slave(agent?)
should accept commands from anyone who knows the url and the
incantation.  It should only accept commands from its master, and it
needs some way of verifying that the master actually is who it says it

> Supposed to be, when you attach a slave to the build environment, all
> installations in the slave will be copied to the master and you can only add
> installations to the build environment from those installations.

Okay.  What if I stop, reconfigure, and start a slave?  Do I have to
delete and re-add it to the master to get it to pick up the new
configuration?  (Will I be _able_ to delete it, if it is associated to
a build environment?)

>> Also, we're already blocked from releasing trunk because we have no
>> database migration capability.  Given that the target market for
>> distributed builds is Continuum users who have _multiple_ instances,
>> how are they going to migrate and combine multiple sets of
>> configuration into one master server?

This is still a major concern of mine.  I have a dozen Continuum
instances with projects/schedules/installations/build environments ...
how am I going to get all of that into my new single master server?

Again, except for the "Understanding Distributed Builds" document and
Emmanuel's request to use annotations, I don't see a reason to delay
merging it to trunk. :)


View raw message