RFC for VIP17: unix domain sockets for listen and backend addresses

[Dridi Boukelmoune]

> Dridi, I'm sorry I never answered all of this, after you put the
> effort into responding.

No worries, thanks for the feedback :)

> On a tight schedule today (and I unfortunately can't make it to
> bugwash today, May 8th), but I'd like to elaborate on this part a bit.

We haven't decided on the next occurrence of the v6 planning so it's fine.

> What I forgot to say in WIP17: I would suggest a varnishd parameter
> uds_path, paralleling vcl_path and vmod_path, which specifies a path
> in which to search for relative UDS paths in a -a argument and in
> backend definitions.

I think uds_path would be awkward. Please note that listen addresses
are immutable once the manager setup is over (which wasn't the case up
to 4.0) so whatever we put on the command line, we stick to it. It
means that a parameter as in varnishd -p of the dynamic persuasion
wouldn't fit in the picture.

> From that it follows that we couldn't identify a UDS address
> unambiguously as having a '/' as the first character, which is why I
> think we should require the 'unix:' prefix (or some other prefix).

For the reason explained above, I think we would be better off with
sticking to absolute paths. Less complexity, no prefix, and no
possible collision with IP addresses and port numbers.

Also, a named address would look like this:

    varnishd -a public_https=unix:<path>,PROXY

We'd be stacking new syntax on new syntax, I'm not too happy with the idea.

> I think experience has shown that absolute paths in the Varnish
> configuration, which used to be necessary for "include", for example,
> leads to awkward problems, and the two *_path parameters have been a
> relief. And I think we'll find that requiring absolute paths
> everywhere for UDS addresses will lead to the same kinds of problems
> -- say, you're running a test instance of your Varnish deployment in
> an environment where files and directories a laid out differently from
> the production environment. So then you'd have to get sed or something
> replace all of the absolute paths, just like we used to have to do
> with absolute include paths.

I would be happy to make that someone else's problem (like all those
"devops" fancy tools to manage environments).

> So I say do it right from the beginning this time, and make it
> possible to use relative paths and just change the uds_path parameter
> when you have to.

Define "when you have to", as I said earlier listen addresses are
immutable once the manager is started. That's a condition that
we must hold since we are to expose them in VCL.

> Notice that if we do have relative paths, it's not impossible to have
> a file named "127.0.0.1", or anything else that looks just like an IP
> address, as the file that's meant to be a UDS address. Of course
> that's very unlikely and just asking for trouble. But the point is
> that, strictly speaking, we *couldn't* have an unambiguous distinction
> between IP and UDS addresses *unless* we require all UDS paths to be
> absolute (and begin with a '/').
>
> I say let's do everyone a favor by having uds_path and the 'unix:' prefix.

Please let me know whether this opinion still holds.

--

As agreed during the v6 planning I'm also updating the draft for VIP
17 according to the outcome of our discussions. This is still work in
progress but you can have a look at the current version:

https://github.com/varnishcache/varnish-cache/wiki/VIP-17:-Enable-Unix-domain-sockets-for-listen-and-backend-addresses/7c181afe87ef3f3ecb24967906f41d51a8813c5e

The draft acknowledges the fact that the "named listen addresses"
change has officially been accepted. I used VIP17 as a convenient
placeholder for the named listen addresses spec and tried to write the
whole thing in a way that could be usable for documentation or release
notes.

The main part of the draft (How ?) has yet to be written. It will take
more time as I need to read the v6 planning minutes more carefully.

Best,
Dridi