Changes between Version 2 and Version 3 of Master Slave Protocol
- Timestamp:
- Jun 13, 2005, 11:42:51 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Master Slave Protocol
v2 v3 1 1 = Bitten Master/Slave Protocol = 2 3 [[PageOutline(2)]] 2 4 3 5 To decouple the master and slave, an application protocol will be defined on top of the meta-protocol BEEP (Blocks Extensible Exchange Protocol, [http://www.faqs.org/rfcs/rfc3080.html RFC 3080]). BEEP was chosen because it provides peer-to-peer communication (so that both the client and the server can send requests to the other) and because of its relative simplicity compared to protocols such as XMPP. 4 6 5 == Scenarios == 6 7 === Slave Registration === 7 == Slave Registration == 8 8 9 9 A new client connects to the build master and signals its' availability for executing builds by starting a channel for the Bitten profile. … … 12 12 * Platform/architecture 13 13 * Operating system 14 * The product name and version number of each of the dependencies of the project to build (for example, the C compiler or the Python runtime). There may be multiple versions of each installed.14 * The product name and version number of each of the dependencies of the project to build (for example, the C compiler or the Python runtime). 15 15 * Name and email address of the maintainer 16 17 After the Bitten channel has been started, the client would send a message like this to the server: 18 {{{ 19 MSG 1 0 . 0 78 20 Content-Type: application/beep+xml 21 22 <sysinfo name="levi" maintainer="Christopher Lenz <cmlenz@gmx.de>"> 23 <platform family="powerpc">Power Macintosh</platform> 24 <os family="posix" version="8.1.0">Darwin</os> 25 </sysinfo> 26 END 27 }}} 28 29 The server acknowledges that it received the registration with a positive or negative reply. 16 30 17 31 Next, the server checks whether there are any pending builds for that client. For example, if it is the only client that supports GCC 4.0, and there has been no build of some revision with GCC 4 yet, it will initiate a build on that client. Anyway, the server remembers the client configuration for as long as the connection is open, and may choose to route build requests to that client when repository changes are detected, or a build is triggered otherwise. 18 32 19 == = Build Initiation ===33 == Build Initiation == 20 34 21 35 When the build server detects that builds are necessary for some revision of the project, it queries its database of available slaves and chooses a set of slaves with non-overlapping configurations. For example, if there are 10 clients available that could execute the build of a Java project on Windows 2000 with JDK 1.4, it will only select one of those to actually perform the build. 22 36 23 A client can at any time decline a build request (or even abort a build), in which case the build master selects the next available client with the same (or sufficiently similar) configuration. 37 A build request 38 {{{ 39 MSG 1 1 . 0 78 40 Content-Type: application/beep+xml 41 42 <build config="trunk"/> 43 END 44 }}} 45 46 A client can decline a build request (or even abort a build), in which case the build master selects the next available client with the same (or sufficiently similar) configuration. 24 47 25 48 If the client accepts a build request, the server will transmit a tarball of the code base that is to be built. The client does not need to know which exact revision (or branch) of the project it is building, nor does it need to perform a checkout itself. 26 49 27 === Build Status Reporting === 50 {{{ 51 MSG 1 2 * 0 78 52 Content-Type: application/tar 53 Content-Encoding: gzip 54 55 ... 56 }}} 57 58 == Build Status Reporting == 28 59 29 60 Before and after each step of the [wiki:BuildRecipes build recipe], the client informs the server about its status:
