Move manifests/varnish.pp to a module

Change-Id: I12f9956c9a16829b4bcf53820c5df110dc81fbb5
Move htcppurger.pp to the right dir

Change-Id: I229af071ce7a2084bd48578e2a36599e86dfaddf
Retry starting Varnish 3 times on temp error 75

Change-Id: Ifd8a9fae6aafe58dcff15ddb4a2e5bc226808a24
Fix test

Change-Id: Ibdc0430278e44ebf88994ec5a2ea46298dadb271
Allow persistent connections for HTTP PURGE (error) responses

Varnish always closes the HTTP connection when going through vcl_error.
Because we use vcl_error for things like purging, geoip and redirects,
this is suboptimal. We've patched Varnish to support persistent
connections when the object's Connection: response header is set to
"keep-alive", and the client allows it.

Varnish overwrites the Connection: response header if it
determines it needs to close anyway, so no need to be careful in
VCL for it.

Change-Id: I33ea1753ce37512f7532e090e426a29f351bcd3e
Revert "Allow persistent connections for HTTP PURGE (error) responses"

Need to restart frontends first

This reverts commit f3914d9b5e27b6e5c50e705a48f842bc078c9665.

Change-Id: Ibe308e786c920617456fec8448130c1390e751c4
Revert "Revert "Allow persistent connections for HTTP PURGE (error) responses""

This reverts commit fd5273a5fdbf6766b386a90a983fe4b7ab44b9e0.

Change-Id: Iaf5801f9f41469d3d9edfc7205c885e12102af3c
Revert "Allow persistent connections for HTTP PURGE (error) responses" - causing problems with vhtcpd

Revert for now, investigate later

This reverts commit be44d6fa1a2421deb5b7951e44f2dcb936ef2664.

Change-Id: I5a9f16eb52d3346394ffcdb9e39023cd3f4030d8
Allow persistent connections for HTTP PURGE (error) responses via 204

This reverts the revert in 7233f4b2fb966e681e37753d542882b03127c057,
  and changes the PURGE error codes from 200 to 204, which allows
  the vhtcpd parser to detect end-of-message correctly.

Change-Id: Ife5a0db654b46d467a886ec0834ae388439e8fdb
Add sysctlfile module and one use case.

Change-Id: I7f114d47a965014003d2042578bbe0c6091a51f4
Factor out XFF append handling into a common function

Change-Id: I42587b856dfc533bd25358d9bd514d4a1119582a
Generate ganglia plugin conf after starting Varnish

Change-Id: Ib40de2a8ba9e96f86140b7ca8f1eafe65762b05c
Install extra VCL files before starting Varnish

Change-Id: I354e48cdad0c557ac844ee1ea97a09e5cf108190
get rid of varnishhtcpd upstart job

On beta deployment-cache-text1 I end up with two version of the Varnish
HTCPD purger:
- vhtcpd : from Debian package, started with init script
- varnishhtcpd : from puppet, started with upstart

The two copy race for UDP port 4827 and cause much havoc on the beta
caches.  There might be the same issue in production as well.

The Perl HTCP purger daemon has been removed in d64e7aa
 https://gerrit.wikimedia.org/r/#/c/68687/

Change-Id: If86d785362c635cfa97adb07efea222b84eacb1e
Merge "get rid of varnishhtcpd upstart job" into production
Fix typo, files -> file

How did this ever get past Jenkins?

Change-Id: I641b6519bfe4a4f843cbcabc52e52cee95f2f591
Fix XFF handling on all Varnish clusters

X-Forwarded-For handling is a total mess.

Change-Id: Ica2bc6b7c2ed8844e1442e48ee92df13541a952f
Don't use absolute URIs for purging

Change-Id: I50a76153055a262ec628fa437c0bf4922c0319d1
Add max-age/s-maxage on CC: private/no-cache responses

Varnish does not respect Cache-Control: private or no-cache,
supposedly because "Varnish is not a cache in the RFC2616" sense.
https://www.varnish-cache.org/trac/ticket/1124

Change-Id: I19167342de721530a1968c20779418a73dd3143d
Set req.hash_ignore_busy = true for PURGE requests

PURGE requests should never wait for busy objects to finish a fetch.
I suspect this may be the reason why some PURGE requests take a long
time.

Change-Id: I77d54b5826237228e0d6847743d3d1c0770f29c8