It would be convenient to be able to use a locally built version of DataPlaneAPI for this process. One approach might be to rename the variable to dataplaneapi_location and allow the Ansible tasks to determine if it's a file/URL, and use copy/get_url appropriately (I have a topic branch with this approach that seems to work, though since I'm new to Ansible, it may not be the cleanest)
FWIW, it's already possible to override the DataPlaneAPI URL by setting up PACKER_FLAGS to set the correct var
Using modified (ie. not officially released) DataPlaneAPI binaries in an HAProxy OVA build.
Motivation:
In cases where a DataPlaneAPI client sets up check-ssl without passing in the check flag, you can end up with a situation where the backend is configured to use SSL for it's health checks, but without 'check', it's always considered up and therefore no health checks are performed.
In cases where a DataPlaneAPI client is always requesting SSL for health checks, we may want to disable it from a DataPlaneAPI standpoint (As not all backends may be serving SSL traffic) - this could be a workaround until we determine a path forward on such clients. (it could be nice if we allowed end users to hint whether their LB will be serving SSL traffic or not, for instance)
I've been working around the above with a patched DataPlaneAPI build that -
looks for the presence of 'check-ssl' to determine if health checks should be enabled (which @akutz put together)
Strips out the check-ssl flag (to avoid enforcing health checks over SSL)
Working with a patched DataPlaneAPI binary, while not a long term fix, allows using health checks in a specific way without requiring modifications to the client. In this case, the client is an operator in a running K8s cluster that won't be upgraded in the short term, even though that operator is where we probably want these kinds of policy decisions coming from in the long run. Still, doing this via DPAPI today gives us a 'break glass' approach to setting up health checks correctly. (it's a fairly simple patch to DataPlaneAPI, see the topic branch linked below, which contains the two fixes I mentioned above.)
dataplaneapi/ $ go version
go version go1.14 darwin/amd64
dataplaneapi/ $ GOOS=linux make build # you'll want GOOS if you're cross compiling (on a Mac, for instance)
dataplaneapi/ $ file build/dataplaneapi
build/dataplaneapi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
scp the dataplane API to the running HAProxy instance
Today, the packer build process only consumes the DataPlaneAPI binary from a URL.
A URL is passed in via a user variable - https://github.com/haproxytech/vmware-haproxy/blob/master/packer.json#L9
This variable is then used in an Ansible
get_urltask https://github.com/haproxytech/vmware-haproxy/blob/master/ansible/roles/haproxy/tasks/main.yml#L15It would be convenient to be able to use a locally built version of DataPlaneAPI for this process. One approach might be to rename the variable to
dataplaneapi_locationand allow the Ansible tasks to determine if it's a file/URL, and usecopy/get_urlappropriately (I have a topic branch with this approach that seems to work, though since I'm new to Ansible, it may not be the cleanest)FWIW, it's already possible to override the DataPlaneAPI URL by setting up PACKER_FLAGS to set the correct var
Use case:
Motivation:
check-sslwithout passing in thecheckflag, you can end up with a situation where the backend is configured to use SSL for it's health checks, but without 'check', it's always considered up and therefore no health checks are performed.I've been working around the above with a patched DataPlaneAPI build that -
check-sslflag (to avoid enforcing health checks over SSL)Working with a patched DataPlaneAPI binary, while not a long term fix, allows using health checks in a specific way without requiring modifications to the client. In this case, the client is an operator in a running K8s cluster that won't be upgraded in the short term, even though that operator is where we probably want these kinds of policy decisions coming from in the long run. Still, doing this via DPAPI today gives us a 'break glass' approach to setting up health checks correctly. (it's a fairly simple patch to DataPlaneAPI, see the topic branch linked below, which contains the two fixes I mentioned above.)
Replacing DataplaneAPI binary in live environment
scpthe dataplane API to the running HAProxy instanceSSH into the HAProxy instance for the rest of the steps-
The new DataplaneAPI build should now be working.