> Le 19 juin 2017 à 15:06, William Lallemand <[email protected]> a écrit : > > On Mon, Jun 19, 2017 at 11:26:31AM +0200, Emmanuel Hocdet wrote: >> >> Exactly, use case is to upgrade haproxy from a 1.6/1.7/1.8 compatibility to >> 1.8 with master worker. >> > > That's insteresting, I will do some tests in order to be able to do this > properly. > >> >> It's much simpler than I thought (with mworker). >> Perhaps keep -x internal to mworker and not expose it to legacy mode could >> be less >> confused for users. >> I will try my test upgrade without -x. >> > > If you want to upgrade one "legacy" process which was not a master worker, you > will still need it. > > However, if you already have a master worker process running, it will load the > new version of the binary from where it was first executed and then add the -x > itself when forking its new workers on a reload. > > Some people still want to use the -x feature without the master-worker, and > that's useful in your usecase, if your socket path changed in the > configuration > file. >
In case of upgrade from haproxy without -x option to -x, i suppose it will do cleanly. I try to play with -x, multi-proc (add and remove), upgrade pre -x without master-worker and is painful. Perhaps i misunderstood (and i used multi -x). Now, i only test from legacy to -x with master-worker. > I think that's just a matter of documentation, maybe I can write a longer > paragraph in the management.txt doc explaining how to upgrade for the legacy > mode, and what changed between this one and the master worker. Yes, documentation must be sufficient to avoid bad usages. What about case of multi -x? Manu
