docs: use Vinyl Cache as primary name (formerly Varnish Cache)

The FOSS project was renamed from Varnish Cache to Vinyl Cache in Sept 2025
(https://vinyl-cache.org/). Update README and all docs to use the new name
while keeping "formerly Varnish Cache" for discoverability. Technical names
(VCL, varnishadm, vmods) are unchanged as those are tool-level names.

Also removes kube-httpcache reference from architecture.md.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: cloud-vinyl-bot

README.md

@@ -1,14 +1,15 @@
 # cloud-vinyl
 
-Kubernetes operator for managing Varnish Cache clusters.
+Kubernetes operator for managing [Vinyl Cache](https://vinyl-cache.org/) clusters
+(the FOSS HTTP cache formerly known as Varnish Cache).
 
 ## Features
 
 - **Operator pattern** — central controller with reconcile loop, no sidecar antipattern
 - **Multiple backends** — first-class support for multiple backend services
-- **VCL lifecycle management** — generates and pushes VCL config to Varnish pods via vinyl-agent
+- **VCL lifecycle management** — generates and pushes VCL config to Vinyl Cache pods via vinyl-agent
 - **Invalidation** — integrated PURGE/BAN and xkey (surrogate key) support
-- **Clustering** — shard director for Varnish peer routing
+- **Clustering** — shard director for Vinyl Cache peer routing
 - **PROXY Protocol** — optional upstream PROXY protocol support
 - **Non-root by default** — all containers run as non-root
 - **Helm chart** — first-class Helm deployment

docs/sources/explanation/architecture.md

@@ -1,8 +1,8 @@
 # Architecture
 
-cloud-vinyl is a Kubernetes operator that manages Varnish Cache clusters as first-class Kubernetes resources.
-It is a clean-room reimplementation of [mittwald/kube-httpcache](https://github.com/mittwald/kube-httpcache),
-designed around the Kubernetes operator pattern with a central controller instead of per-pod sidecars.
+cloud-vinyl is a Kubernetes operator that manages [Vinyl Cache](https://vinyl-cache.org/) clusters
+(the FOSS HTTP cache formerly known as Varnish Cache) as first-class Kubernetes resources.
+It is designed around the Kubernetes operator pattern with a central controller instead of per-pod sidecars.
 
 ## Components
 
@@ -11,7 +11,7 @@ graph TD
     subgraph Kubernetes cluster
         OP[cloud-vinyl operator<br/>Deployment]
         VC[VinylCache CR]
-        SS[StatefulSet<br/>Varnish pods]
+        SS[StatefulSet<br/>Vinyl Cache pods]
         AG[vinyl-agent<br/>sidecar per pod]
         PX[Purge/BAN proxy<br/>port 8090]
         WH[Admission webhook<br/>port 9443]
@@ -20,7 +20,7 @@ graph TD
     OP -->|manages| SS
     SS -->|contains| AG
     OP -->|pushes VCL| AG
-    AG -->|manages Varnish| VCL[Varnish process]
+    AG -->|manages Vinyl Cache| VCL[Vinyl Cache process]
     PX -->|PURGE/BAN broadcast| SS
     WH -->|defaults + validates| VC
 ```
@@ -38,33 +38,33 @@ The operator is a single Deployment that runs the reconcile loop. It:
 
 ### vinyl-agent
 
-A lightweight HTTP server running as a sidecar in each Varnish pod.
-It wraps the Varnish admin interface (port 6082) and exposes:
+A lightweight HTTP server running as a sidecar in each Vinyl Cache pod.
+It wraps the Vinyl Cache admin interface (port 6082) and exposes:
 
 - `POST /vcl/push` — compile and activate a new VCL.
 - `GET /vcl/active` — return the hash of the currently active VCL.
-- `POST /ban` — issue a Varnish `ban` command.
+- `POST /ban` — issue a ban command.
 
 Communication between the operator and vinyl-agent is authenticated with a pod-scoped token stored in a Kubernetes Secret.
 
 ### Purge/BAN proxy
 
 The operator exposes an HTTP endpoint on port `8090` that accepts:
 
-- `PURGE /<path>` — HTTP PURGE broadcast to all Varnish pods.
+- `PURGE /<path>` — HTTP PURGE broadcast to all Vinyl Cache pods.
 - `POST /ban` or `BAN` method — validated ban expression, forwarded to vinyl-agent `/ban` on all pods.
 - `POST /purge/xkey` — xkey-based purge, one `PURGE` per key with `X-Xkey-Purge` header.
 
 Upstream services send a single request; the operator fans it out to all pods in parallel.
 
 ## Why a central operator instead of sidecars?
 
-The original kube-httpcache runs a per-pod signaller sidecar that watches the Kubernetes Endpoints
-API and triggers VCL reloads. This design has several problems:
+A per-pod signaller sidecar design that watches the Kubernetes Endpoints API and triggers VCL reloads
+has several structural problems:
 
 1. **Chicken-and-egg at startup**: pods with readiness gates cannot become ready until the sidecar
    receives the first VCL push — but the sidecar needs other pods to be ready to build the peer list.
-2. **Silent drop on failure**: if a VCL push fails, kube-httpcache logs and continues.
+2. **Silent drop on failure**: if a VCL push fails, the sidecar logs and continues.
    Pods silently run stale VCL.
 3. **No debouncing**: rapid endpoint churn (rolling restarts) triggers many VCL regenerations back-to-back.
 

docs/sources/explanation/invalidation.md

@@ -19,7 +19,7 @@ PURGE http://<operator-svc>:8090/path/to/resource
 
 ## BAN (expression-based)
 
-Bans invalidate sets of objects matching a Varnish expression.
+Bans invalidate sets of objects matching a VCL expression.
 The most common pattern is banning by URL prefix or response header:
 
 ```

docs/sources/how-to/create-cache.md

@@ -1,6 +1,6 @@
 # Create a VinylCache cluster
 
-This guide creates a minimal Varnish Cache cluster using a `VinylCache` custom resource.
+This guide creates a minimal Vinyl Cache cluster using a `VinylCache` custom resource.
 
 ## Minimal example
 
@@ -31,7 +31,7 @@ kubectl get vinylcache my-cache -w
 ```
 
 The operator creates:
-- A `StatefulSet` with 2 Varnish pods (+ vinyl-agent sidecar per pod).
+- A `StatefulSet` with 2 Vinyl Cache pods (+ vinyl-agent sidecar per pod).
 - A headless `Service` for pod-to-pod communication.
 - A traffic `Service` for upstream connections.
 - An invalidation `Service` + `EndpointSlice` for the operator's Purge/BAN proxy.

docs/sources/index.md

@@ -1,6 +1,7 @@
 # cloud-vinyl
 
-A Kubernetes Operator for managing Varnish Cache clusters as first-class Kubernetes resources.
+A Kubernetes Operator for managing [Vinyl Cache](https://vinyl-cache.org/) clusters
+(the FOSS HTTP cache formerly known as Varnish Cache) as first-class Kubernetes resources.
 
 ```{toctree}
 :maxdepth: 2

docs/sources/reference/vinylcache-spec.md

@@ -12,7 +12,7 @@
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
-| `replicas` | integer | yes | Number of Varnish pods in the StatefulSet. |
+| `replicas` | integer | yes | Number of Vinyl Cache pods in the StatefulSet. |
 | `backends` | list | yes | One or more backend services. |
 | `director` | object | no | Director configuration (defaults: `type: shard`). |
 | `cluster` | object | no | Clustering / peer-routing configuration. |
@@ -24,7 +24,7 @@
 | `proxyProtocol.enabled` | boolean | no | Enable PROXY protocol v2 on port 8081. |
 | `proxyProtocol.port` | integer | no | PROXY protocol port (default: `8081` when enabled). |
 | `service.annotations` | object | no | Annotations on the traffic Service. |
-| `pod.labels` | object | no | Extra labels on Varnish pods. |
+| `pod.labels` | object | no | Extra labels on Vinyl Cache pods. |
 
 ### backends
 

docs/sources/tutorials/quickstart.md

@@ -1,6 +1,6 @@
 # Quickstart
 
-This tutorial deploys a complete Varnish Cache cluster in a local kind cluster in under 10 minutes.
+This tutorial deploys a complete Vinyl Cache cluster in a local kind cluster in under 10 minutes.
 
 ## Prerequisites
 
@@ -78,10 +78,10 @@ kubectl get vinylcache quickstart -w
 # quickstart   True    2/2        True   Ready     45s
 ```
 
-## 7. Send a request through Varnish
+## 7. Send a request through Vinyl Cache
 
 ```bash
-# Port-forward the Varnish traffic service
+# Port-forward the Vinyl Cache traffic service
 kubectl port-forward svc/quickstart-traffic 8080:8080 &
 
 # First request: cache MISS