On Mon, Jan 12, 2009 at 7:38 AM, Marica Tan <[email protected]> wrote: > On Sat, Jan 10, 2009 at 12:52 AM, Wendy Smoak <[email protected]> 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 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?) >> 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. :) -- Wendy
