continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marica Tan" <>
Subject Re: First Part of Distributed Builds
Date Tue, 13 Jan 2009 02:37:50 GMT
On Tue, Jan 13, 2009 at 9:18 AM, Wendy Smoak <> wrote:

> 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.

Just saw it earlier thanks :)

> > 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".

Will change it to CONTINUUM_BUILD_AGENT_HOME then and the agent's url to
buildagent-xmlrpc .

> > 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...

Actually it's not part of the first pass yet because i'm not sure how to get
the svn changes since it can build on a different slave each time. Maybe we
should just check out the source code on the master, that way continuum
master will know if there have been svn changes. So when you build a project
in a distributed builds mode, the master will also update the source code of
the project. Unless you have other suggestions?

> >> 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
> is.
> > 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?)

You need not delete and re-add the slave to the master. When you access the
build environment with the attached slave, it should retrieve all available
installations from that slave and add the new installations to the master.

You won't be able to delete a build agent if it's associated with a build

> >> 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?

We still need to have a migration plan for this :)

> 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. :)
> --
> Wendy


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message