It'd be interesting to know the complete semantics of the feature you are implementing. I know you understand that our use case is a valid one. And we are open to explore alternative approaches to achieve the same. Till then we will be running haproxy with the flag change reverted and wait for your response on this. On Sep 18, 2015 1:25 AM, "Baptiste" <bed...@gmail.com> wrote:
> On Thu, Sep 17, 2015 at 9:42 PM, Pavlos Parissis > <pavlos.paris...@gmail.com> wrote: > > On 15/09/2015 08:45 πμ, Cyril Bonté wrote: > >> Hi, > >> > >> > >> Le 14/09/2015 14:23, Ayush Goyal a écrit : > >>> Hi, > >>> > >>> We are testing haproxy-1.6dev4, we have added a server in backend as > >>> disabled, but we are not able > >>> to bring it up using socket command. > >>> > >>> Our backend conf looks like this: > >>> > >>> =====cut==== > >>> backend apiservers > >>> server api101 localhost:1234 maxconn 128 weight 1 > >>> check > >>> server api102 localhost:1235 disabled maxconn 128 weight 1 > >>> check > >>> server api103 localhost:1236 disabled maxconn 128 weight 1 > >>> check > >>> =====cut==== > >>> > >>> But, when I run the "enable apiservers/api103" command, it is still in > >>> MAINT mode. Disabling and enabling of non "disabled" servers like > api101 > >>> are happening properly. > >>> > >>> Enabling a config "disabled" server works correctly with haproxy1.5. > Can > >>> you confirm whether its a bug in 1.6-dev4? > >> > >> This is due to the introduction of the SRV_ADMF_CMAINT flag, which is > >> set permanently. The "enable/disable" socket command will only modify > >> the SRV_ADMF_FMAINT and SRV_ADMF_FDRAIN flags. > >> > >> I add Baptiste to the thread. > >> > > > > That will break our setup as well, where an external tool uses the > > socket to disable a server in the running config and regenerate the > > configuration with the server disabled. > > > > I am also interested in knowing the motivation behind this change. > > > > Cheers, > > Pavlos > > > > > > Hi all, > > This "feature" was an early patch for later coming feature to avoid > any impact of reloading HAProxy on servers state. > I'm currently finishing the dev before forwarding the patches to Willy > by tomorrow. > We needed to know the real reason why a server was in maintenance > state: was it because of configuration or through the socket, so at > next reload we could apply the right state based on old running state, > old config state and new config state. > > I'm going to check what we can do to fix your issue. > > Baptiste > >
