For the first iteration I just dynamically added server to proxy and then called check_config_validity() which resolves all track's and checks things. IMHO check_config_validity() need some refactoring, because in current state it not only check config, but also resolves some dependencies and state, so it can't be called repeatedly. It can be done in two ways - move resolving of all those thing to separate function(s) or place additional checks to prevent overwrtiting data that is already in memory.
Now after you wrote about possible problems I'll look into them and try to find ways to fix them. I'll let you know with some patches if I will find some good way to do it. The more people looking into it the more ways to find better solution :) Michał 2017-01-20 11:02 GMT+01:00 Willy Tarreau <w...@1wt.eu>: > On Thu, Jan 19, 2017 at 11:54:32PM +0100, Micha?? wrote: > > Hello, > > > > What do you think about making possible to add servers to backend at > > runtime via CLI/socket? > > This is exactly what is being worked on, but it's not as trivial as you > imagine :-) > > > Changing addresses and wieghts of servers is ok, > > because we can use "placeholders", but it's not the best solution and > > requires to configure many placeholders when it comes to autoscaling. > > We'll still use placeholders, we'll just ensure they're more discrete. > Eg with Baptiste we discussed the idea of a "server template" which > would declare a number of server slots at once that will be usable to > be enabled on the CLI or via the DNS. > > > This problem solves reloading haproxy with safe loading certificates to > > encrypted volume which takes some time and in dynamically changing world > of > > microservices - it just kills whole load balancing solutions with endless > > reloads. > > Sure it solves a lot of things but it creates a veeeeeeeery long trail of > new problems at the same time. Just one example : assigning automatic > cookie values for servers created on the fly, that do not conflict with > existing ones and which are invariant between multiple LB nodes and along > DNS updates. Another one ? Consistent server IDs across all LBs for shared > stickiness and consistent stats. There will also be quite a number of > functional limitations, such as the impossibility to use such servers > in "use-server" directives, the impossibility to reference them in ACLs > (eg: srv_is_up()), impossibility to track them from other servers, etc. > All this because these references are resolved upon startup and are > mandatory to validate the consistency of the configuration. > > But some progress is being made in this area (and in 1.7 you can at least > start a server with no address and fill it later, which is a huge progress > compared to 1.6). > > Best regards, > Willy >
