We could put it under
set service ha-proxy
It has many features and options so we should start by making inventory of minimum-required and what is nice-to-have.
We could put it under
set service ha-proxy
It has many features and options so we should start by making inventory of minimum-required and what is nice-to-have.
Just to voice my opinion, I vote strongly against implementing haproxy support. In my opinion this is feature bloat, we should be striving to do networking, not application level load balancing.
Also puppet/ansible/favourite-cf-management-system modules for haproxy exist. My guess is none of the existing users of haproxy would convert and with vyos 1.x it is difficult to support any kind of automation, so I doubt someone validating plain haproxy configuration with the help of a configuration management system would decide for vyos.
As an engineer working using vyos and HAproxy in many customer environments I would say to keep those solutions apart. Vyos is a great network appliance and HAproxy is an load balancer. They can work together really nice and I dont see a reason to tie them up together.
We need to rename this maybe,
as it actually have nothing to do with HAproxy
Actually, idea is to reuse Keepalived which provide VRRP functionality to cover additional use case