Le 18/01/2020 à 13:10, Aleksandar Lazic a écrit :
Hi.
The nuster proxy modifies haproxy.c and adds some structs and function calls
into the haproxy main code.
Examples:
https://github.com/jiangwenyuan/nuster/blob/master/src/haproxy.c#L182
https://github.com/jiangwenyuan/nuster/blob/master/src/haproxy.c#L2243
https://github.com/jiangwenyuan/nuster/blob/master/src/haproxy.c#L2744
When I look to the prometheus-exporter which also enhances the haproxy with a
service, what's the best way to migrate the nuster to none modifying enhancement
plugin?
http://git.haproxy.org/?p=haproxy.git;a=blob;f=contrib/prometheus-exporter/service-prometheus.c;h=0f178eb64e2a376d2b56ac7ce3a71d88438246e7;hb=HEAD
I would like to create a 'contrib/nuster' to be able to build nuster in a
similar
way like the prometheus-exporter.
My steps in mind.
* download/git clone nuster
* download/git clone haproxy
* cd to haproxy
* make TARGET=linux-glibc EXTRA_OBJS="contrib/nuster/nuster.o"
NUSTER_DIR="/path/to/nuster/root/dir"
Due to the fact that prom-extporter does not add statments to '.global' I'm
not sure if the enhancement is possible or make sense.
Opinions?
Hi Aleks,
First of all, I don't really know how nuster works. As far as I can see, some
updates to nuster is required to do such plugin. First of all, it should not
extend the global structure. Instead it should use its own global private
structure. 51Degrees, Wurfl and DeviceAtlas already do it. In the same spirit,
it should not add a rule list in the proxy structure. It may rely on the
existing HTTP ruleset adding some keywords. Or it may use a list in the nuster
filters configuration. Then, it should be HTX aware. Finally, a task must be
created to manage the calls to the function nuster_housekeeping(). It is of
course totally impossible to call it from the polling loop.
So to answer your question, with some changes in nuster, it is probably
technically possible to create a service using nuster code. The main problem I
see is the maintainability of this plugin. Nuster evolves in parallel of
HAProxy. It is a fork of it, it is not a patchset on top of it. The nuster
developer never tried to make its project compatible with HAProxy. Or at least,
he never asked anything on the mailing list. So, of course, it is its own right.
There is no problem with that. But it could be a good idea to have a better view
on how the project will evolve to evaluate the pertinence of a nuster plugin.
Honestly, if you ever do the effort to work on it, it could be better to rewrite
all the project as a plugin of HAProxy and not a fork of it. If so, it is
probably a better idea to keep it in a separate repository though. This will be
easier to push new features, without the burden to submit the patches on the ML.
Of course, it could be good to have the opinion of the nuster's developer, to
know if he is up for doing some changes this way.
--
Christopher Faulet
