On Mon, Jan 20, 2020 at 10:06:20PM +0100, Christopher Faulet wrote: > 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.
I totally agree with this. If some minor extensions to haproxy would be needed to do his thing better (maybe one hook here and there), we could get them merged to ease his maintenance as long as they have zero impact on the rest. But given that the project has been evolving for a few years now, occasionally rebasing on new version, I guess the developer possibly makes a living from his fork and has no particular interest in seeing his code more easily used without him being kept in the loop. Of couse I could be totally wrong but that's what it makes me think of. I don't think we should bother him. He took care of renaming the project so as to present it as a self-contained cache and not as a load balancer, and as such he doesn't cause any harm to the haproxy project. And he seems to be doing his job right by regularly merging stable branches, so I'm not seeing anything wrong there that we should encourage to change. If all projects forks were done this way, we'd all have less crap installed on our machines. Of course it would be nice if he would participate a bit to the project, but well, how could we expect any contribution back from anyone using haproxy ? He will already have a tough work migrating to HTX :-) Aleks, if you're interested in this project, I think you should contact him. I suspect he will tell you he only covers the caching part and uses haproxy only as the HTTP/TCP engine to run his cache, as is visible in his example config, and that if you want to use a load balancer, he will invite you to use a separate haproxy process. And that's important given that he's doing file system accesses (hence high latencies and limited security)! Regards, Willy
