blob: feda50728c4f9b63307d810158e84c5ebcd82413 [file] [log] [blame]
Willy Tarreaub1a34b62010-05-09 22:37:12 +02001 ----------------------
2 HAProxy how-to
3 ----------------------
Willy Tarreau7b66e302015-05-02 15:20:38 +02004 version 1.5.12
Willy Tarreaub1a34b62010-05-09 22:37:12 +02005 willy tarreau
Willy Tarreau7b66e302015-05-02 15:20:38 +02006 2015/05/02
willy tarreau78345332005-12-18 01:33:16 +01007
8
Willy Tarreaub1a34b62010-05-09 22:37:12 +020091) How to build it
10------------------
11
Willy Tarreau869f3512014-06-19 15:26:32 +020012First, please note that this version is a stable version, so in general if you
13are not used to build from sources, it is recommended that instead you follow
14the packaged updates provided by your software vendor or Linux distribution.
15Most of them are taking this task seriously and are doing a good job. If for
16any reason you'd prefer a different version than the one packaged for your
17system, or to get some commercial support, other choices are available at :
18
19 http://www.haproxy.com/
20
willy tarreau78345332005-12-18 01:33:16 +010021To build haproxy, you will need :
Willy Tarreaub1a34b62010-05-09 22:37:12 +020022 - GNU make. Neither Solaris nor OpenBSD's make work with the GNU Makefile.
Willy Tarreau3543cdb2014-05-10 09:12:46 +020023 If you get many syntax errors when running "make", you may want to retry
24 with "gmake" which is the name commonly used for GNU make on BSD systems.
Willy Tarreau869f3512014-06-19 15:26:32 +020025 - GCC between 2.95 and 4.8. Others may work, but not tested.
willy tarreau78345332005-12-18 01:33:16 +010026 - GNU ld
27
28Also, you might want to build with libpcre support, which will provide a very
Willy Tarreaub1a34b62010-05-09 22:37:12 +020029efficient regex implementation and will also fix some badness on Solaris' one.
willy tarreau78345332005-12-18 01:33:16 +010030
31To build haproxy, you have to choose your target OS amongst the following ones
32and assign it to the TARGET variable :
33
Willy Tarreau83b30c12008-05-25 10:32:50 +020034 - linux22 for Linux 2.2
35 - linux24 for Linux 2.4 and above (default)
36 - linux24e for Linux 2.4 with support for a working epoll (> 0.21)
Willy Tarreau83b30c12008-05-25 10:32:50 +020037 - linux26 for Linux 2.6 and above
Willy Tarreau869f3512014-06-19 15:26:32 +020038 - linux2628 for Linux 2.6.28, 3.x, and above (enables splice and tproxy)
Willy Tarreau83b30c12008-05-25 10:32:50 +020039 - solaris for Solaris 8 or 10 (others untested)
Willy Tarreau869f3512014-06-19 15:26:32 +020040 - freebsd for FreeBSD 5 to 10 (others untested)
Willy Tarreau8624cab2013-04-02 08:17:43 +020041 - osx for Mac OS/X
Willy Tarreau3b8e9792012-11-22 00:43:09 +010042 - openbsd for OpenBSD 3.1 to 5.2 (others untested)
Willy Tarreau50abe302014-04-02 20:44:43 +020043 - aix51 for AIX 5.1
Willy Tarreau7dec9652012-06-06 16:15:03 +020044 - aix52 for AIX 5.2
Yitzhak Sapir32087312009-06-14 18:27:54 +020045 - cygwin for Cygwin
Willy Tarreau869f3512014-06-19 15:26:32 +020046 - generic for any other OS or version.
Willy Tarreau83b30c12008-05-25 10:32:50 +020047 - custom to manually adjust every setting
willy tarreau78345332005-12-18 01:33:16 +010048
49You may also choose your CPU to benefit from some optimizations. This is
50particularly important on UltraSparc machines. For this, you can assign
51one of the following choices to the CPU variable :
52
53 - i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon
54 - i586 for intel Pentium, AMD K6, VIA C3.
55 - ultrasparc : Sun UltraSparc I/II/III/IV processor
Willy Tarreau94fb38f2014-07-10 20:24:25 +020056 - native : use the build machine's specific processor optimizations. Use with
57 extreme care, and never in virtualized environments (known to break).
58 - generic : any other processor or no CPU-specific optimization. (default)
willy tarreau78345332005-12-18 01:33:16 +010059
Willy Tarreau83b30c12008-05-25 10:32:50 +020060Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
61for your platform.
62
Willy Tarreauef7341d2009-04-11 19:45:50 +020063You may want to build specific target binaries which do not match your native
64compiler's target. This is particularly true on 64-bit systems when you want
65to build a 32-bit binary. Use the ARCH variable for this purpose. Right now
Willy Tarreaua5899aa2010-11-28 07:41:00 +010066it only knows about a few x86 variants (i386,i486,i586,i686,x86_64), two
67generic ones (32,64) and sets -m32/-m64 as well as -march=<arch> accordingly.
Willy Tarreauef7341d2009-04-11 19:45:50 +020068
willy tarreau78345332005-12-18 01:33:16 +010069If your system supports PCRE (Perl Compatible Regular Expressions), then you
70really should build with libpcre which is between 2 and 10 times faster than
71other libc implementations. Regex are used for header processing (deletion,
72rewriting, allow, deny). The only inconvenient of libpcre is that it is not
73yet widely spread, so if you build for other systems, you might get into
74trouble if they don't have the dynamic library. In this situation, you should
75statically link libpcre into haproxy so that it will not be necessary to
Willy Tarreau83b30c12008-05-25 10:32:50 +020076install it on target systems. Available build options for PCRE are :
willy tarreau78345332005-12-18 01:33:16 +010077
Willy Tarreau83b30c12008-05-25 10:32:50 +020078 - USE_PCRE=1 to use libpcre, in whatever form is available on your system
willy tarreau78345332005-12-18 01:33:16 +010079 (shared or static)
80
Willy Tarreau83b30c12008-05-25 10:32:50 +020081 - USE_STATIC_PCRE=1 to use a static version of libpcre even if the dynamic
82 one is available. This will enhance portability.
83
Willy Tarreau663148c2012-12-12 00:38:22 +010084 - with no option, use your OS libc's standard regex implementation (default).
Willy Tarreau83b30c12008-05-25 10:32:50 +020085 Warning! group references on Solaris seem broken. Use static-pcre whenever
86 possible.
willy tarreau78345332005-12-18 01:33:16 +010087
Willy Tarreau64bc40b2011-03-23 20:00:53 +010088Recent systems can resolve IPv6 host names using getaddrinfo(). This primitive
89is not present in all libcs and does not work in all of them either. Support in
90glibc was broken before 2.3. Some embedded libs may not properly work either,
91thus, support is disabled by default, meaning that some host names which only
92resolve as IPv6 addresses will not resolve and configs might emit an error
93during parsing. If you know that your OS libc has reliable support for
94getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to enable
95it. This is the recommended option for most Linux distro packagers since it's
96working fine on all recent mainstream distros. It is automatically enabled on
97Solaris 8 and above, as it's known to work.
98
Willy Tarreau3543cdb2014-05-10 09:12:46 +020099It is possible to add native support for SSL using the GNU makefile, by passing
100"USE_OPENSSL=1" on the make command line. The libssl and libcrypto will
101automatically be linked with haproxy. Some systems also require libz, so if the
102build fails due to missing symbols such as deflateInit(), then try again with
103"ADDLIB=-lz".
Willy Tarreaud4508812012-09-10 09:07:41 +0200104
Lukas Tribus3fe9f1e2013-05-19 16:28:17 +0200105To link OpenSSL statically against haproxy, build OpenSSL with the no-shared
106keyword and install it to a local directory, so your system is not affected :
107
108 $ export STATICLIBSSL=/tmp/staticlibssl
109 $ ./config --prefix=$STATICLIBSSL no-shared
110 $ make && make install_sw
111
Lukas Tribus130ddf72013-10-01 00:28:03 +0200112When building haproxy, pass that path via SSL_INC and SSL_LIB to make and
113include additional libs with ADDLIB if needed (in this case for example libdl):
Willy Tarreau3543cdb2014-05-10 09:12:46 +0200114
Lukas Tribus130ddf72013-10-01 00:28:03 +0200115 $ make TARGET=linux26 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl
Lukas Tribus3fe9f1e2013-05-19 16:28:17 +0200116
William Lallemand82fe75c2012-10-23 10:25:10 +0200117It is also possible to include native support for ZLIB to benefit from HTTP
118compression. For this, pass "USE_ZLIB=1" on the "make" command line and ensure
119that zlib is present on the system.
120
willy tarreau78345332005-12-18 01:33:16 +0100121By default, the DEBUG variable is set to '-g' to enable debug symbols. It is
122not wise to disable it on uncommon systems, because it's often the only way to
123get a complete core when you need one. Otherwise, you can set DEBUG to '-s' to
124strip the binary.
125
126For example, I use this to build for Solaris 8 :
127
Willy Tarreau83b30c12008-05-25 10:32:50 +0200128 $ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1
willy tarreau78345332005-12-18 01:33:16 +0100129
Willy Tarreau83b30c12008-05-25 10:32:50 +0200130And I build it this way on OpenBSD or FreeBSD :
willy tarreaud38e72d2006-03-19 20:56:52 +0100131
Willy Tarreau3543cdb2014-05-10 09:12:46 +0200132 $ gmake TARGET=freebsd USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
willy tarreaud38e72d2006-03-19 20:56:52 +0100133
Willy Tarreau663148c2012-12-12 00:38:22 +0100134And on a classic Linux with SSL and ZLIB support (eg: Red Hat 5.x) :
135
Willy Tarreau94fb38f2014-07-10 20:24:25 +0200136 $ make TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
Willy Tarreau663148c2012-12-12 00:38:22 +0100137
138And on a recent Linux >= 2.6.28 with SSL and ZLIB support :
Willy Tarreaud4508812012-09-10 09:07:41 +0200139
Willy Tarreau94fb38f2014-07-10 20:24:25 +0200140 $ make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
Willy Tarreaud4508812012-09-10 09:07:41 +0200141
William Lallemand82fe75c2012-10-23 10:25:10 +0200142In order to build a 32-bit binary on an x86_64 Linux system with SSL support
143without support for compression but when OpenSSL requires ZLIB anyway :
Willy Tarreauef7341d2009-04-11 19:45:50 +0200144
Willy Tarreaud4508812012-09-10 09:07:41 +0200145 $ make TARGET=linux26 ARCH=i386 USE_OPENSSL=1 ADDLIB=-lz
Willy Tarreauef7341d2009-04-11 19:45:50 +0200146
Willy Tarreaub1efede2014-05-09 00:44:48 +0200147The SSL stack supports session cache synchronization between all running
148processes. This involves some atomic operations and synchronization operations
149which come in multiple flavors depending on the system and architecture :
150
151 Atomic operations :
152 - internal assembler versions for x86/x86_64 architectures
153
154 - gcc builtins for other architectures. Some architectures might not
155 be fully supported or might require a more recent version of gcc.
156 If your architecture is not supported, you willy have to either use
157 pthread if supported, or to disable the shared cache.
158
159 - pthread (posix threads). Pthreads are very common but inter-process
160 support is not that common, and some older operating systems did not
161 report an error when enabling multi-process mode, so they used to
162 silently fail, possibly causing crashes. Linux's implementation is
163 fine. OpenBSD doesn't support them and doesn't build. FreeBSD 9 builds
164 and reports an error at runtime, while certain older versions might
165 silently fail. Pthreads are enabled using USE_PTHREAD_PSHARED=1.
166
167 Synchronization operations :
168 - internal spinlock : this mode is OS-independant, light but will not
169 scale well to many processes. However, accesses to the session cache
170 are rare enough that this mode could certainly always be used. This
171 is the default mode.
172
173 - Futexes, which are Linux-specific highly scalable light weight mutexes
174 implemented in user-space with some limited assistance from the kernel.
175 This is the default on Linux 2.6 and above and is enabled by passing
176 USE_FUTEX=1
177
178 - pthread (posix threads). See above.
179
180If none of these mechanisms is supported by your platform, you may need to
181build with USE_PRIVATE_CACHE=1 to totally disable SSL cache sharing. Then
182it is better not to run SSL on multiple processes.
183
willy tarreau78345332005-12-18 01:33:16 +0100184If you need to pass other defines, includes, libraries, etc... then please
185check the Makefile to see which ones will be available in your case, and
Willy Tarreau3543cdb2014-05-10 09:12:46 +0200186use the USE_* variables in the Makefile.
willy tarreau78345332005-12-18 01:33:16 +0100187
Willy Tarreau97ec9692010-01-28 20:52:05 +0100188AIX 5.3 is known to work with the generic target. However, for the binary to
189also run on 5.2 or earlier, you need to build with DEFINE="-D_MSGQSUPPORT",
Willy Tarreau869f3512014-06-19 15:26:32 +0200190otherwise __fd_select() will be used while not being present in the libc, but
191this is easily addressed using the "aix52" target. If you get build errors
192because of strange symbols or section mismatches, simply remove -g from
193DEBUG_CFLAGS.
Willy Tarreau97ec9692010-01-28 20:52:05 +0100194
Willy Tarreau32e65ef2013-04-02 08:14:29 +0200195You can easily define your own target with the GNU Makefile. Unknown targets
196are processed with no default option except USE_POLL=default. So you can very
197well use that property to define your own set of options. USE_POLL can even be
198disabled by setting USE_POLL="". For example :
199
200 $ gmake TARGET=tiny USE_POLL="" TARGET_CFLAGS=-fomit-frame-pointer
201
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200202
2032) How to install it
204--------------------
205
206To install haproxy, you can either copy the single resulting binary to the
207place you want, or run :
208
209 $ sudo make install
210
211If you're packaging it for another system, you can specify its root directory
212in the usual DESTDIR variable.
213
214
2153) How to set it up
216-------------------
217
218There is some documentation in the doc/ directory :
219
220 - architecture.txt : this is the architecture manual. It is quite old and
221 does not tell about the nice new features, but it's still a good starting
222 point when you know what you want but don't know how to do it.
223
224 - configuration.txt : this is the configuration manual. It recalls a few
225 essential HTTP basic concepts, and details all the configuration file
226 syntax (keywords, units). It also describes the log and stats format. It
227 is normally always up to date. If you see that something is missing from
Willy Tarreau74774c02014-04-23 00:57:08 +0200228 it, please report it as this is a bug. Please note that this file is
229 huge and that it's generally more convenient to review Cyril Bonté's
230 HTML translation online here :
231
232 http://cbonte.github.io/haproxy-dconv/configuration-1.5.html
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200233
234 - haproxy-en.txt / haproxy-fr.txt : these are the old outdated docs. You
235 should never need them. If you do, then please report what you didn't
236 find in the other ones.
237
238 - gpl.txt / lgpl.txt : the copy of the licenses covering the software. See
239 the 'LICENSE' file at the top for more information.
240
241 - the rest is mainly for developers.
242
243There are also a number of nice configuration examples in the "examples"
244directory as well as on several sites and articles on the net which are linked
245to from the haproxy web site.
246
247
2484) How to report a bug
249----------------------
250
251It is possible that from time to time you'll find a bug. A bug is a case where
252what you see is not what is documented. Otherwise it can be a misdesign. If you
253find that something is stupidly design, please discuss it on the list (see the
254"how to contribute" section below). If you feel like you're proceeding right
255and haproxy doesn't obey, then first ask yourself if it is possible that nobody
256before you has even encountered this issue. If it's unlikely, the you probably
257have an issue in your setup. Just in case of doubt, please consult the mailing
258list archives :
259
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200260 http://marc.info/?l=haproxy
261
262Otherwise, please try to gather the maximum amount of information to help
263reproduce the issue and send that to the mailing list :
264
265 haproxy@formilux.org
266
267Please include your configuration and logs. You can mask your IP addresses and
268passwords, we don't need them. But it's essential that you post your config if
269you want people to guess what is happening.
270
271Also, keep in mind that haproxy is designed to NEVER CRASH. If you see it die
272without any reason, then it definitely is a critical bug that must be reported
273and urgently fixed. It has happened a couple of times in the past, essentially
274on development versions running on new architectures. If you think your setup
275is fairly common, then it is possible that the issue is totally unrelated.
276Anyway, if that happens, feel free to contact me directly, as I will give you
277instructions on how to collect a usable core file, and will probably ask for
278other captures that you'll not want to share with the list.
279
280
2815) How to contribute
282--------------------
283
284It is possible that you'll want to add a specific feature to satisfy your needs
285or one of your customers'. Contributions are welcome, however I'm often very
286picky about changes. I will generally reject patches that change massive parts
287of the code, or that touch the core parts without any good reason if those
288changes have not been discussed first.
289
290The proper place to discuss your changes is the HAProxy Mailing List. There are
291enough skilled readers to catch hazardous mistakes and to suggest improvements.
Willy Tarreau9a639a12011-09-10 22:48:36 +0200292I trust a number of them enough to merge a patch if they say it's OK, so using
293the list is the fastest way to get your code reviewed and merged. You can
294subscribe to it by sending an empty e-mail at the following address :
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200295
296 haproxy+subscribe@formilux.org
297
Willy Tarreau9a639a12011-09-10 22:48:36 +0200298If you have an idea about something to implement, *please* discuss it on the
299list first. It has already happened several times that two persons did the same
300thing simultaneously. This is a waste of time for both of them. It's also very
301common to see some changes rejected because they're done in a way that will
302conflict with future evolutions, or that does not leave a good feeling. It's
303always unpleasant for the person who did the work, and it is unpleasant for me
304too because I value people's time and efforts. That would not happen if these
305were discussed first. There is no problem posting work in progress to the list,
306it happens quite often in fact. Also, don't waste your time with the doc when
307submitting patches for review, only add the doc with the patch you consider
308ready to merge.
309
Willy Tarreau2ddccb72013-05-01 10:07:21 +0200310Another important point concerns code portability. Haproxy requires gcc as the
311C compiler, and may or may not work with other compilers. However it's known
312to build using gcc 2.95 or any later version. As such, it is important to keep
313in mind that certain facilities offered by recent versions must not be used in
314the code :
315
316 - declarations mixed in the code (requires gcc >= 3.x)
317 - GCC builtins without checking for their availability based on version and
318 architecture ;
319 - assembly code without any alternate portable form for other platforms
320 - use of stdbool.h, "bool", "false", "true" : simply use "int", "0", "1"
321 - in general, anything which requires C99 (such as declaring variables in
322 "for" statements)
323
324Since most of these restrictions are just a matter of coding style, it is
325normally not a problem to comply.
326
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200327If your work is very confidential and you can't publicly discuss it, you can
328also mail me directly about it, but your mail may be waiting several days in
329the queue before you get a response.
330
331If you'd like a feature to be added but you think you don't have the skills to
332implement it yourself, you should follow these steps :
333
334 1. discuss the feature on the mailing list. It is possible that someone
335 else has already implemented it, or that someone will tell you how to
336 proceed without it, or even why not to do it. It is also possible that
337 in fact it's quite easy to implement and people will guide you through
338 the process. That way you'll finally have YOUR patch merged, providing
339 the feature YOU need.
340
341 2. if you really can't code it yourself after discussing it, then you may
342 consider contacting someone to do the job for you. Some people on the
Willy Tarreau869f3512014-06-19 15:26:32 +0200343 list might sometimes be OK with trying to do it.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200344
345Note to contributors: it's very handy when patches comes with a properly
Willy Tarreau9a639a12011-09-10 22:48:36 +0200346formated subject. There are 3 criteria of particular importance in any patch :
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200347
Willy Tarreau9a639a12011-09-10 22:48:36 +0200348 - its nature (is it a fix for a bug, a new feature, an optimization, ...)
349 - its importance, which generally reflects the risk of merging/not merging it
350 - what area it applies to (eg: http, stats, startup, config, doc, ...)
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200351
Willy Tarreau9a639a12011-09-10 22:48:36 +0200352It's important to make these 3 criteria easy to spot in the patch's subject,
353because it's the first (and sometimes the only) thing which is read when
354reviewing patches to find which ones need to be backported to older versions.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200355
Willy Tarreau9a639a12011-09-10 22:48:36 +0200356Specifically, bugs must be clearly easy to spot so that they're never missed.
357Any patch fixing a bug must have the "BUG" tag in its subject. Most common
358patch types include :
359
360 - BUG fix for a bug. The severity of the bug should also be indicated
361 when known. Similarly, if a backport is needed to older versions,
362 it should be indicated on the last line of the commit message. If
363 the bug has been identified as a regression brought by a specific
364 patch or version, this indication will be appreciated too. New
365 maintenance releases are generally emitted when a few of these
366 patches are merged.
367
368 - CLEANUP code cleanup, silence of warnings, etc... theorically no impact.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200369 These patches will rarely be seen in stable branches, though they
Willy Tarreau9a639a12011-09-10 22:48:36 +0200370 may appear when they remove some annoyance or when they make
371 backporting easier. By nature, a cleanup is always minor.
372
373 - REORG code reorganization. Some blocks may be moved to other places,
374 some important checks might be swapped, etc... These changes
375 always present a risk of regression. For this reason, they should
376 never be mixed with any bug fix nor functional change. Code is
377 only moved as-is. Indicating the risk of breakage is highly
378 recommended.
379
380 - BUILD updates or fixes for build issues. Changes to makefiles also fall
381 into this category. The risk of breakage should be indicated if
382 known. It is also appreciated to indicate what platforms and/or
383 configurations were tested after the change.
384
385 - OPTIM some code was optimised. Sometimes if the regression risk is very
386 low and the gains significant, such patches may be merged in the
387 stable branch. Depending on the amount of code changed or replaced
388 and the level of trust the author has in the change, the risk of
389 regression should be indicated.
390
391 - RELEASE release of a new version (development or stable).
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200392
Willy Tarreau9a639a12011-09-10 22:48:36 +0200393 - LICENSE licensing updates (may impact distro packagers).
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200394
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200395
Willy Tarreau9a639a12011-09-10 22:48:36 +0200396When the patch cannot be categorized, it's best not to put any tag. This is
397commonly the case for new features, which development versions are mostly made
398of.
399
400Additionally, the importance of the patch should be indicated when known. A
401single upper-case word is preferred, among :
402
403 - MINOR minor change, very low risk of impact. It is often the case for
404 code additions that don't touch live code. For a bug, it generally
405 indicates an annoyance, nothing more.
406
407 - MEDIUM medium risk, may cause unexpected regressions of low importance or
408 which may quickly be discovered. For a bug, it generally indicates
409 something odd which requires changing the configuration in an
410 undesired way to work around the issue.
411
412 - MAJOR major risk of hidden regression. This happens when I rearrange
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200413 large parts of code, when I play with timeouts, with variable
414 initializations, etc... We should only exceptionally find such
Willy Tarreau9a639a12011-09-10 22:48:36 +0200415 patches in stable branches. For a bug, it indicates severe
416 reliability issues for which workarounds are identified with or
417 without performance impacts.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200418
Willy Tarreau9a639a12011-09-10 22:48:36 +0200419 - CRITICAL medium-term reliability or security is at risk and workarounds,
420 if they exist, might not always be acceptable. An upgrade is
421 absolutely required. A maintenance release may be emitted even if
422 only one of these bugs are fixed. Note that this tag is only used
423 with bugs. Such patches must indicate what is the first version
424 affected, and if known, the commit ID which introduced the issue.
425
426If this criterion doesn't apply, it's best not to put it. For instance, most
427doc updates and most examples or test files are just added or updated without
428any need to qualify a level of importance.
429
430The area the patch applies to is quite important, because some areas are known
431to be similar in older versions, suggesting a backport might be desirable, and
432conversely, some areas are known to be specific to one version. When the tag is
433used alone, uppercase is preferred for readability, otherwise lowercase is fine
434too. The following tags are suggested but not limitative :
435
436 - doc documentation updates or fixes. No code is affected, no need to
437 upgrade. These patches can also be sent right after a new feature,
438 to document it.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200439
Willy Tarreau9a639a12011-09-10 22:48:36 +0200440 - examples example files. Be careful, sometimes these files are packaged.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200441
Willy Tarreau9a639a12011-09-10 22:48:36 +0200442 - tests regression test files. No code is affected, no need to upgrade.
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200443
Willy Tarreau9a639a12011-09-10 22:48:36 +0200444 - init initialization code, arguments parsing, etc...
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200445
Willy Tarreau9a639a12011-09-10 22:48:36 +0200446 - config configuration parser, mostly used when adding new config keywords
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200447
Willy Tarreau9a639a12011-09-10 22:48:36 +0200448 - http the HTTP engine
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200449
Willy Tarreau9a639a12011-09-10 22:48:36 +0200450 - stats the stats reporting engine as well as the stats socket CLI
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200451
Willy Tarreau9a639a12011-09-10 22:48:36 +0200452 - checks the health checks engine (eg: when adding new checks)
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200453
Willy Tarreau9a639a12011-09-10 22:48:36 +0200454 - acl the ACL processing core or some ACLs from other areas
455
456 - peers the peer synchronization engine
457
458 - listeners everything related to incoming connection settings
459
460 - frontend everything related to incoming connection processing
461
462 - backend everything related to LB algorithms and server farm
463
464 - session session processing and flags (very sensible, be careful)
465
466 - server server connection management, queueing
467
468 - proxy proxy maintenance (start/stop)
469
470 - log log management
471
472 - poll any of the pollers
473
474 - halog the halog sub-component in the contrib directory
475
476 - contrib any addition to the contrib directory
477
478Other names may be invented when more precise indications are meaningful, for
479instance : "cookie" which indicates cookie processing in the HTTP core. Last,
480indicating the name of the affected file is also a good way to quickly spot
481changes. Many commits were already tagged with "stream_sock" or "cfgparse" for
482instance.
483
484It is desired that AT LEAST one of the 3 criteria tags is reported in the patch
485subject. Ideally, we would have the 3 most often. The two first criteria should
486be present before a first colon (':'). If both are present, then they should be
487delimited with a slash ('/'). The 3rd criterion (area) should appear next, also
488followed by a colon. Thus, all of the following messages are valid :
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200489
490Examples of messages :
Willy Tarreau9a639a12011-09-10 22:48:36 +0200491 - DOC: document options forwardfor to logasap
492 - DOC/MAJOR: reorganize the whole document and change indenting
493 - BUG: stats: connection reset counters must be plain ascii, not HTML
494 - BUG/MINOR: stats: connection reset counters must be plain ascii, not HTML
495 - MEDIUM: checks: support multi-packet health check responses
496 - RELEASE: Released version 1.4.2
497 - BUILD: stats: stdint is not present on solaris
498 - OPTIM/MINOR: halog: make fgets parse more bytes by blocks
499 - REORG/MEDIUM: move syscall redefinition to specific places
500
501Please do not use square brackets anymore around the tags, because they give me
502more work when merging patches. By default I'm asking Git to keep them but this
503causes trouble when patches are prefixed with the [PATCH] tag because in order
504not to store it, I have to hand-edit the patches. So as of now, I will ask Git
505to remove whatever is located between square brackets, which implies that any
506subject formatted the old way will have its tag stripped out.
507
508In fact, one of the only square bracket tags that still makes sense is '[RFC]'
509at the beginning of the subject, when you're asking for someone to review your
510change before getting it merged. If the patch is OK to be merged, then I can
511merge it as-is and the '[RFC]' tag will automatically be removed. If you don't
512want it to be merged at all, you can simply state it in the message, or use an
513alternate '[WIP]' tag ("work in progress").
514
515The tags are not rigid, follow your intuition first, anyway I reserve the right
516to change them when merging the patch. It may happen that a same patch has a
517different tag in two distinct branches. The reason is that a bug in one branch
518may just be a cleanup in the other one because the code cannot be triggered.
519
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200520
521For a more efficient interaction between the mainline code and your code, I can
522only strongly encourage you to try the Git version control system :
523
524 http://git-scm.com/
525
526It's very fast, lightweight and lets you undo/redo your work as often as you
527want, without making your mistakes visible to the rest of the world. It will
528definitely help you contribute quality code and take other people's feedback
529in consideration. In order to clone the HAProxy Git repository :
530
Willy Tarreau869f3512014-06-19 15:26:32 +0200531 $ git clone http://git.haproxy.org/git/haproxy-1.5.git (stable 1.5)
Willy Tarreau6346f0a2014-05-10 11:04:39 +0200532 $ git clone http://git.haproxy.org/git/haproxy.git/ (development)
Willy Tarreau663148c2012-12-12 00:38:22 +0100533
Willy Tarreaub1a34b62010-05-09 22:37:12 +0200534If you decide to use Git for your developments, then your commit messages will
535have the subject line in the format described above, then the whole description
536of your work (mainly why you did it) will be in the body. You can directly send
537your commits to the mailing list, the format is convenient to read and process.
538
willy tarreau78345332005-12-18 01:33:16 +0100539-- end