Re: haproxy 1.9 status update

[Baptiste]

Sorry to wake up an old thread, but I'm very concerned by the lack of
"architecture guide" documentation with HAProxy.
Did we make any progress on this topic?

Baptiste

Re: haproxy 1.9 status update

[Willy Tarreau]

Hi Baptiste,

On Sun, Jun 10, 2018 at 09:27:09AM +0200, Baptiste wrote:
> Hi Willy,
> 
> I don't see anywhere DNS over TCP mentioned.

I have reported what I'm aware people are currently working on, as you
know I don't want to speculate anymore about what would be nice to have
if someone was willing to work on it, since the roadmap file is already
full of this.

> From my point of view (and integration with consul / kubernetes), it's an
> important topic and I'd like to get it done by 1.9, ideally.
> I have not checked yet how this could be implemented in HAProxy, but I
> don't really feel comfortable to do it, I'm afraid it's a huge task and I
> won't have enough time to do it.

I certainly can understand, but first it means that someone will have
to step up saying "I'm willing to work on this" and second you'll have
to find at least enough time to help this person and go back and forth
with the review, and later for the debugging. As you know this is not
a negligible part of the job at all!

Cheers,
Willy

Re: haproxy 1.9 status update

[Baptiste]

Hi Willy,

I don't see anywhere DNS over TCP mentioned.
>From my point of view (and integration with consul / kubernetes), it's an
important topic and I'd like to get it done by 1.9, ideally.
I have not checked yet how this could be implemented in HAProxy, but I
don't really feel comfortable to do it, I'm afraid it's a huge task and I
won't have enough time to do it.

Baptiste

Re: haproxy 1.9 status update

[Baptiste]

Hi,

Thanks all for the amazing work :)

I just like to focus on a particular point:

  - wiki : we all know that the architecture guide is obsolete, everyone
> wants to refresh it and nobody can because it's a tedious task that
> no single person can address, and nobody anymore knows all haproxy
> pieces. In addition a lot of participants have useful tips to share
> and would be much more at ease with putting this into a wiki than by
> editing architecture.txt. Thus I'd like to reuse either Github or
> Gitlab's wiki to place real contents edited and maintained by the
> community, and to kill this obsolete file. This way the obsolete stuff
> on the main haproxy.org page could go as well.
>
>
Here is my wish list for such architecture guide:
- gitfied
- "generic" formatting language (markdown, restructured text, etc...)
- ability to update pages using command line on a local PC or a browser (I
know github allows  editing content online)

I have no idea what tools may be best suited for this purpose, but I'd like
we decide to use one quickly, so I can start contributing to it.

Cheers

PS: I'm testing github pages at the moment.

Re: haproxy 1.9 status update

[Aleksandar Lazic]

Hi Willy.

Finally I found the time to write a answer.

On 25/05/2018 18:10, Willy Tarreau wrote:

Hi all,

I've long wanted to send a status update on where haproxy 1.9 is
going, and seeing some recent threads speculating about what will be
available reminded me that it's really time to send this update. Be
careful, this e-mail is long.


8-O yes but very informative. Thanks for writing.

[snipp]


  - make a "resolvers" section able to use /etc/resolv.conf [Ben]. Baptiste
is going to take a look at this very soon, I think we should be good
soon on this one.


Are there any plans for DoH (= https://github.com/curl/curl/wiki/DNS-over-HTTPS)

[snipp]


  - native HTTP representation allowing end-to-end HTTP/2
[Christopher] : this will allow HTTP/2 to be used end-to-end. For
now Chris is working on the "easy" part which is the HTTP/1
parsing/conversion. I'm putting quotes around "easy" because while
HTTP/1 appears easy to deal with, that's where the highest number
of obstacles are present due to the fact that HTTP/1 is currently
used as the native internal representation (H2 is currently
translated to H1). This will heavily rely on the mux changes.  We
know that some parts ("tcp-request content" L7-based rules, option
http-send-name-header, and filters/compression) will cause some
head scratching. The expected gains from this part are
tremendous. But while I thought that H2 and threads used to be the
most complex changes over the last decade, I think this one's
complexity has already surpassed them both. I'd say the chances of
success for 1.9 are around 70%, which is not much but which still
gives us the motivation for pursuing the efforts. Once completed,
Christopher will deserve a barrel of beer to forget about this
painful task ;-)


Full ack.

That's one part for the gRPC, as Daniel mentioned in a previous mail ;-)

Will this be a 'plugin'?

The idea behind this question is to add another protocol plugin like MQTT
or other protocols

[snipp]


  - SSL layer splitting between FD level and buffer level [Olivier] :
this will be required for QUIC so that we can feed buffers
containing SSL traffic to OpenSSL. For now the SSL layer relies on
OpenSSL's native read()/write()
calls (yes, the ones that force you to disable SIGPIPE in gdb).


This is one question I wanted to ask 'what's the plan for QIUC is.'
Sounds like it's on the roadmap.


Some ideas to study later, nothing really assigned :
  - certificates : study if it makes sense to parse them on the fly on
first use to also save on startup time.

  - logs: some improvements to the logging system have been discussed
about a few times, which can be summarized like this :
  - some people would like a set of log "profiles" that can be
reused everywhere instead of copy-pasting the same log-format
lines.
  - some people really need a per-server log-format because they
send, say, native logs locally and JSON logs to another
server.
  - some people want to load-balance between log servers
  - other people want to sample logs without having to trick the
config 
  => all of this has to be addressed together.


* How about to let rsyslog handle this. There are queues and pools and
ratelimits also are there some recipes how to create json logs.

or

* How about to build a dedicated worker for this like SPOE which handles
the specific logging requirement?

Jm2C


  - the "return" directive, regularly talked about, may possible be done
for 1.9.


8-O What's this?

[snipp]


Last point, as some of you might have noticed, we finally recovered
the haproxy GitHub account (thanks to Jeff for this as well as Dan,
Lukas and Joe for helping coordinate the operations). A new haproxy
repository was placed there only with mainline for now. By the way if
you're having a fork from more than one month ago, chances are that
you accidently forked the wrong one ;-)

We do have a few plans with this account now, some of which seem
appealing, and others who don't sound really compatible with some
annoying GitHub limitations, making me think that maybe in the end we
should switch to Gitlab (William already created haproxy.org there) :


OH I like gitlab much more then github ;-)


  - re-enable issues : we still don't have a public bug tracker/todo
list and it's a pain for everyone. It would be nice to show what's
pending or being worked on, and to sometimes add extra info
regarding a given task. The problem we've faced in the past with
GitHub's issue tracker is that it's impossible to restrict the
creation of new issues to participants. Given that haproxy is a
complex component, the boundary between human error,
misunderstanding and bug is extremely thin. It resulted in the
issue tracker being filled with wrong bugs, 100% of which were in
fact requests for help. It makes the utility totally 

Re: haproxy 1.9 status update

[Frederic Lecaille]

On 05/25/2018 06:10 PM, Willy Tarreau wrote:

Hi all,


[sniped]


   - peers over SSL [Fred] : the purpose is to allow all bind options with
 peers so that peers can exchange information securely. I think I've
 seen it posted somewhere, I'll have to dig through the archives.


Here are the rebased patches for this feature.

Fred.

>From e41942d0c85dd4270a685e5db5bf8523e87ef287 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 28 May 2018 08:47:52 +0200
Subject: [PATCH 10/10] DOC: peers: Update "peers" section SSL/TLS support
 documentation.

---
 doc/configuration.txt | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index e27d666..544b697 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1833,6 +1833,12 @@ peers 
   Creates a new peer list with name . It is an independent section,
   which is referenced by one or more stick-tables.
 
+bind [param*]
+  Defines the binding parameters of the local peer of this "peers" section.
+  To avoid some redundancy, and as the  and  parameters
+  are already provided on "peer" (or "server") lines, they are not supported
+  by "bind" keyword in "peers" sections.
+
 disabled
   Disables a peers section. It disables both listening and any synchronization
   related to this section. This is provided to disable synchronization of stick
@@ -1841,7 +1847,7 @@ disabled
 enable
   This re-enables a disabled peers section which was previously disabled.
 
-peer  :
+peer  : [param*]
   Defines a peer inside a peers section.
   If  is set to the local peer name (by default hostname, or forced
   using "-L" command line option), haproxy will listen for incoming remote peer
@@ -1860,6 +1866,15 @@ peer  :
   You may want to reference some environment variables in the address
   parameter, see section 2.3 about environment variables.
 
+  Note: "peer" keyword may transparently be replaced by "server" keyword (see
+  "server" keyword explanation below).
+
+server  : [param*]
+  As previously mentionned, "peer" keyword may be replaced by "server" keyword
+  with a support for all "server" parameters found in 5.2 paragraph.
+  Some of these parameters are irrelevant for "peers" sections.
+
+
   Example:
 peers mypeers
 peer haproxy1 192.168.0.1:1024
-- 
2.1.4

>From a546f38d9e6fe980c477b91df0681ac6fa0289a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 27 Apr 2018 13:56:13 +0200
Subject: [PATCH 09/10] MINOR: peers: Make incoming connections to SSL/TLS
 local peer work.

This patch makes "bind" work in "peers" sections. All "bind" settings
are supported, excepted ip:port parameters which are provided on
"peer" (or server) line matching the local peer.
After having parsed the configuration files ->prepare_bind_conf is run
to initialize all SSL/TLS stuff for the local peer.
---
 src/cfgparse.c | 95 ++
 1 file changed, 90 insertions(+), 5 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 96ccc9f..90735e6 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1992,6 +1992,31 @@ static int init_peers_frontend(const char *file, int linenum,
 	return 0;
 }
 
+/* Only change ->file, ->line and ->arg struct bind_conf member values
+ * if already present.
+ */
+static struct bind_conf *bind_conf_uniq_alloc(struct proxy *p,
+  const char *file, int line,
+  const char *arg, struct xprt_ops *xprt)
+{
+	struct bind_conf *bind_conf;
+
+	if (!LIST_ISEMPTY(>conf.bind)) {
+		bind_conf = LIST_ELEM((>conf.bind)->n, typeof(bind_conf), by_fe);
+		free(bind_conf->file);
+		bind_conf->file = strdup(file);
+		bind_conf->line = line;
+		if (arg) {
+			free(bind_conf->arg);
+			bind_conf->arg = strdup(arg);
+		}
+	}
+	else {
+		bind_conf = bind_conf_alloc(p, file, line, arg, xprt);
+	}
+
+	return bind_conf;
+}
 /*
  * Parse a line in a ,  or  section.
  * Returns the error code, 0 if OK, or any combination of :
@@ -2012,7 +2037,56 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
 	int err_code = 0;
 	char *errmsg = NULL;
 
-	if (strcmp(args[0], "default-server") == 0) {
+	if (strcmp(args[0], "bind") == 0) {
+		int cur_arg;
+		static int kws_dumped;
+		struct bind_conf *bind_conf;
+		struct bind_kw *kw;
+		char *kws;
+
+		cur_arg = 1;
+
+		if (init_peers_frontend(file, linenum, NULL, curpeers) != 0) {
+			err_code |= ERR_ALERT | ERR_ABORT;
+			goto out;
+		}
+
+		bind_conf = bind_conf_uniq_alloc(curpeers->peers_fe, file, linenum,
+		 NULL, xprt_get(XPRT_RAW));
+		while (*args[cur_arg] && (kw = bind_find_kw(args[cur_arg]))) {
+			int ret;
+
+			ret = kw->parse(args, cur_arg, curpeers->peers_fe, bind_conf, );
+			err_code |= ret;
+			if (ret) {
+if (errmsg 

Re: haproxy 1.9 status update

[Tim Düsterhus]

Willy,

Am 25.05.2018 um 18:10 schrieb Willy Tarreau:
> Not started yet but already planned :
>   - split certificates [William] : some users prefer to have separate .key
> and .crt files (eg for permission reasons). William has already started
> to look and it seems doable, there are "just" a few shortcomings to take
> care of (I don't remember which ones).

This one would be great, as it would save me a bash script to
concatenate the output of certbot into something haproxy understands.

> It's possible I accidently missed someone's tasks, if so, please yell now.
> I'd like that any development outside the scope of what is enumerated above
> and not started yet is not submitted for now, because discussing designs and
> reviewing code takes a huge amount of time and concentration that inevitably
> postpones code progress on planned stuff.

One pain point I am missing from the list is "(add|set)-header" for
redirect responses (or is this part of something else?). We discussed
this briefly in March:

Subject: Re: add header into http-request redirect
Message-ID: <3dd0fbb0-403e-9791-be22-98c7be990...@bastelstu.be>
https://www.mail-archive.com/haproxy@formilux.org/msg29294.html

IMO this is a great example of why an issue tracker is superior to a
mailing list (I'll further get to that below): Things do not get lost in
the stream of other discussion; people can easily re-use the existing
discussion, without fishing for Message-IDs in the mail archive. You
acknowledged that in:

https://www.mail-archive.com/haproxy@formilux.org/msg29358.html
Message-ID: <20180319220157.gh26...@1wt.eu>

> For the next steps given that we've spent a lot of time dealing with bugs and
> painful patches, I'll be a bit more demanding regarding changes. While the
> vast majority of regular contributors have made an awesome progress in the
> quality of their patches, we're still spending some time reviewing huge
> patches that should be broken up into smaller pieces, or re-editing commit
> messages to avoid ruining the life of the -stable team. Sometimes patches

Personally I really want to add my 2ct to some of the patches, but
what's preventing me from doing so is:

1. My email client makes it hard to comment on specific lines in
attachments. That's why I personally send my patches inline (!) using
git send-email / git format-patch.
2. I don't feel like bombarding all the list subscribers with a mail
complaining about typos in commit messages or code comments.
3. The annoying autoresponders of misconfigured Exchange mail servers,
informing me that some random employee of random company is currently
out of office. Every other time I send an email to the list I get
several of those messages back.

I grew up with GitHub and systemd, you don't like those, I very much
like both of them. And for me the barrier to participation would be much
lower using GitHub's Pull Requests.

Yes, Pull Requests encourage drive by committers more than now, but OTOH
you don't know what you might miss out on, both on good patches and on
good review. I know that CONTRIBUTING explicitly mentions pull requests
and merge commits as "bad", but GitHub nowadays supports rebased merges
directly from the web interface, thus avoiding merge commits.

I regularly contribute to various Open Source projects I use using
GitHub pull requests, it's much easier for me to fork the project,
skimming the CONTRIBUTING file and sending a (IMO) high-quality PR that
usually gets merged without much discussion. Often the whole turnaround
time is less than half a day.
For haproxy I would need to subscribe to the list, configure my email
client properly so that my patches don't get mangled, set up filters for
my mail so I don't miss out the review etc.

> We do have a few plans with this account now, some of which seem appealing,
> and others who don't sound really compatible with some annoying GitHub
> limitations, making me think that maybe in the end we should switch to
> Gitlab (William already created haproxy.org there) :

Personal opinion: Use GitHub for the ecosystem. For me GitLab would be
an even greater pain than the mailing list.

>   - re-enable issues : we still don't have a public bug tracker/todo list
> and it's a pain for everyone. It would be nice to show what's pending
> or being worked on, and to sometimes add extra info regarding a given

Very much yes (see above).

> task. The problem we've faced in the past with GitHub's issue tracker
> is that it's impossible to restrict the creation of new issues to
> participants. Given that haproxy is a complex component, the boundary
> between human error, misunderstanding and bug is extremely thin. It
> resulted in the issue tracker being filled with wrong bugs, 100% of
> which were in fact requests for help. It makes the utility totally
> useless for development and bug fixing as it requires more time to
> maintain in a clean state than it takes to put issues in a