Replace Releaser association mechanism through PVC with a Storage Cla…

…ss annotation (#15)

Closes #13

CHANGELOG.md

@@ -7,6 +7,42 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.0] - 2022-12-11
+
+### BREAKING CHANGES
+
+Prior to this change, one of the features of Releaser was to "Automatically associates Releaser with PVs claimed by PVCs that were created by Provisioner with the same `--controller-id`".
+From the `README.md` prior to this change:
+
+> ## PV Releaser Controller
+> 
+> For Releaser to be able to make PVs claimed by Provisioner `Available` after PVC is gone - Releaser and Provisioner must share the same Controller ID.
+> 
+> ### Associate
+> 
+> Once `Released` - PVs doesn't have any indication that they were once associated with a PVC that had association with this Controller ID. To establish this relation - we must catch it while PVC still exists and mark it with our label. If Releaser was down the whole time PVC existed - PV could never be associated making it now orphaned and it will stay as `Released` - Releaser can't know it have to make it `Available`.
+> 
+> Releaser listens for PV creations/updates.
+> The following conditions must be met for a PV to be associated with a Releaser:
+> 
+> - PV doesn't already have `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` association.
+> - `spec.claimRef` must refer to a PVC that either has `metadata.labels."dynamic-pvc-provisioner.kubernetes.io/managed-by"` or `reclaimable-pv-releaser.kubernetes.io/managed-by` set to this Controller ID. If both labels are set - both should point to this Controller ID.
+> - `--disable-automatic-association` must be `false`.
+> 
+> To establish association Releaser will set itself to `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` on this PV.
+
+As disclaimed - that approach was error prone. It was fine most of the time, but if Releaser was down for any noticeable duration of time - it was resulting in PVs piling up in `Released` state, and as the PVC was long gone by then - PVs would remain in that state forever, until manually cleared up.
+
+This mechanism of association through PVC was removed in this release and replaced with a simple Storage Class annotation. In order for Releaser to turn `Released` PV as `Available` - its Storage Class must be annotated with `metadata.annotations."reclaimable-pv-releaser.kubernetes.io/controller-id"` pointing at the `-controller-id` of this Releaser. It can now retro-actively release PVs on startup that it never received events about. As a side effect - `-controller-id` of Provisioner and Releaser doesn't have to match anymore. This unfortunately requires that you use dedicated Storage Class for PVs that must be reclaimable, but that is a fair price to pay if the alternative is unreliable and error prone and might result in expensive storage bills.
+
+You must use Helm charts version `v0.1.0` or above as RBAC is changed in this release to allow read-only access to Storage Classes.
+
+### Changed
+
+- Old PV association via PVC mechanism was removed
+- `-disable-automatic-association` option on Releaser was removed
+- PVs will only be released now if their Storage Class annotated with `metadata.annotations."reclaimable-pv-releaser.kubernetes.io/controller-id"` pointing at the `-controller-id` of this Releaser
+
 ## [0.1.1] - 2022-12-11
 
 ### Fixed

Dockerfile

@@ -3,6 +3,10 @@ FROM golang:1.18 AS build
 ARG RELEASE_STRING=dev
 ENV IMPORT_PATH="github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers"
 WORKDIR /go/delivery
+
+COPY go.mod go.sum ./
+RUN go mod download
+
 COPY . .
 RUN mkdir bin && go build \
     -ldflags "-X ${IMPORT_PATH}.Version=${RELEASE_STRING}" \

README.md

@@ -25,16 +25,15 @@ Dynamic PVC provisioner for pods requesting it via annotations. Automatic PV rel
   - Dynamically create PVC for Pods requesting it via the annotations.
   - Pod is automatically set as `ownerReferences` to the PVC - guaranteeing its deletions upon Pod deletion.
 - PV Releaser
-  - Automatically associates Releaser with PVs claimed by PVCs that were created by Provisioner with the same `--controller-id`.
-  - Deletes `claimRef` from PVs associated with Releaser to move their status from `Released` to `Available` **without deleting any data**.
+  - Keeps track of Storage Classes marked by annotation pointing to the same `--controller-id`.
+  - Deletes `claimRef` from PVs associated with Releaser (via Storage Class annotation) to move their status from `Released` to `Available` **without deleting any data**.
 - Provisioner and Releaser are two separate controllers under one roof, and they can be deployed separately.
   - You can use Provisioner alone for something like Jenkins Kubernetes plugin that doesn't allow PVC creation on its own and automate PVC provisioning from the pod requests. Provisioner on its own will not make PVs automatically reclaimable.
-  - You can use Releaser alone - provided you associate either your PVCs or PVs with it on your own. That will set PVCs able to automatically reclaim associated PVs with whatever data left in it from previous consumer.
-- To make Releaser and Deployer work together - they need to have the same `--controller-id`.
+  - You can use Releaser alone. That will enable PVCs to automatically reclaim PVs with whatever data left in it from previous consumer.
 
 ## Disclaimers
 
-**Provisioner Controller ignores RBAC. If the user creating the Pod didn't had permissions to create PVC - it will still be created as long as Provisioner has access to do it.**
+**Provisioner Controller ignores RBAC. If the user creating the Pod didn't had permissions to create PVC - it will still be created as long as Provisioner has access to do it. Please, use admission controllers.**
 
 **Releaser Controller is by design automatically makes PVs with `reclaimPolicy: Retain` available to be reclaimed by other consumers without cleaning up any data. Use it with caution - this behavior might not be desirable in most cases. Any data left on the PV after the previous consumer will be available to all the following consumers. You may want to use StatefulSets instead. This controller might be ideal for something like build cache - insensitive data by design required to be shared among different consumers. There is many use cases for this, one of them is documented in [examples/jenkins-kubernetes-plugin-with-build-cache](examples/jenkins-kubernetes-plugin-with-build-cache).**
 
@@ -46,15 +45,15 @@ The problem statement for creating this was - I need a pool of CI/CD build cache
 
 ### Why `reclaimPolicy: Retain` is not enough?
 
-When PVC that were using PV with `reclaimPolicy: Retain` is deleted - Kubernetes marks this PV `Released`. Fortunately, this does not let any other PVC to start using it. I say fortunately because imagine if it did - meaning all the data on the volume could be accessed by a new consumer. This is not what `reclaimPolicy: Retain` is designed for - it only allows cluster administrators to recover the data after accidental PVC deletion. Even now deprecated `reclaimPolicy: Recycle` was performing a cleanup before making PV `Available` again. Unfortunately, this just doesn't work for something like a CI/CD build cache, where you intentionally want to reuse data from the previous consumer.
+When PVC that were using PV with `reclaimPolicy: Retain` is deleted - Kubernetes marks this PV `Released`. Fortunately, this will not let any other PVC to use it. I say fortunately because imagine if it did - meaning all the data on the volume could be accessed by a new consumer. This is not what `reclaimPolicy: Retain` is designed for - it only allows cluster administrators to recover the data after accidental PVC deletion. Even now deprecated `reclaimPolicy: Recycle` was performing a cleanup before making PV `Available` again. Unfortunately, this just doesn't work for something like a CI/CD build cache, where you intentionally want to reuse data from the previous consumer.
 
 ### Why not a static PVC?
 
 One way to approach this problem statement would be just to create a static PVC with `accessModes: ["ReadWriteMany"]` - and it would work in most of the cases. But it has certain limitations - let's start with the fact `ReadWriteMany` is not supported by many storage types (example: EBS). The ones that do support it (another popular choice - EFS) most likely based on NFS which does not support an FS-level locking. Even if you got a storage type that supports both `ReadWriteMany` and FS level locking - many tools just doesn't seem to use FS level locking (or have other bugs related to concurrent cache usage). All this can lead to various race conditions failing your builds. That can be solved by making different builds to isolate themselves into a different sub-folders, but that reduces overall efficiency - performance gain will be smaller and you'll have a lot of duplicated cache for commonly used transitive build dependencies.
 
 ### Why not StatefulSets?
 
-StatefulSets are idiomatic way to reuse PVs and preserve data in Kubernetes. It works great for most of the stateful workload types - unfortunately it doesn't suit very well for CI/CD. Build pods are most likely dynamically generated in CI/CD, each pod is crafted for a specific project, with containers to bring in tools that are needed for this specific project. A simple example - one project might need a MySQL container for its unit tests while another might need a PostgreSQL container - but both are Maven projects so both need a Maven cache. You can't do this with StatefulSets where all the pods are exactly the same.
+StatefulSets are idiomatic way to reuse PVs and preserve data in Kubernetes. It works great for most of the stateful workload types - unfortunately it doesn't fit very well for CI/CD. Build pods are most likely dynamically generated in CI/CD, each pod is crafted for a specific project, with containers to bring in tools that are needed for this specific project. A simple example - one project might need a MySQL container for its unit tests while another might need a PostgreSQL container - but both are Maven projects so both need a Maven cache. You can't do this with StatefulSets where all the pods are exactly the same.
 
 ### But why dynamic PVC provisioning from the pod annotations?
 
@@ -172,30 +171,21 @@ dynamic-pvc-provisioner \
 
 ## PV Releaser Controller
 
-For Releaser to be able to make PVs claimed by Provisioner `Available` after PVC is gone - Releaser and Provisioner must share the same Controller ID.
+For Releaser to be able to make PVs claimed by Provisioner `Available` after PVC is gone - Provisioner must be using Storage Class associated with a Releaser.
 
 ### Associate
 
-Once `Released` - PVs doesn't have any indication that they were once associated with a PVC that had association with this Controller ID. To establish this relation - we must catch it while PVC still exists and mark it with our label. If Releaser was down the whole time PVC existed - PV could never be associated making it now orphaned and it will stay as `Released` - Releaser can't know it have to make it `Available`.
-
-Releaser listens for PV creations/updates.
-The following conditions must be met for a PV to be associated with a Releaser:
-
-- PV doesn't already have `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` association.
-- `spec.claimRef` must refer to a PVC that either has `metadata.labels."dynamic-pvc-provisioner.kubernetes.io/managed-by"` or `reclaimable-pv-releaser.kubernetes.io/managed-by` set to this Controller ID. If both labels are set - both should point to this Controller ID.
-- `--disable-automatic-association` must be `false`.
-
-To establish association Releaser will set itself to `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` on this PV.
+Releaser listens for Storage Classes and remembers these that are annotated with `metadata.annotations."reclaimable-pv-releaser.kubernetes.io/controller-id"` pointing to this `-controller-id`. Any PV that is using Storage Class with that annotation is considered associated.
 
 ### Release
 
 Releaser watches for PVs to be released.
 The following conditions must be met for a PV to be made `Available`:
 
-- `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` must be set to this Controller ID.
+- `metadata.annotations."reclaimable-pv-releaser.kubernetes.io/controller-id"` on Storage Class must be set to this Controller ID.
 - `status.phase` must be `Released`.
 
-If these conditions are met, Releaser will set `spec.claimRef` to `null`. That will make Kubernetes eventually to mark `status.phase` of this PV as `Available` - making other PVCs able to reclaim this PV. Releaser will also delete `metadata.labels."reclaimable-pv-releaser.kubernetes.io/managed-by"` to remove association - the next PVC might be managed by something else.
+If these conditions are met, Releaser will set `spec.claimRef` to `null`. That will make Kubernetes eventually to mark `status.phase` of this PV as `Available` - making other PVCs able to reclaim this PV.
 
 ### Usage
 
@@ -207,8 +197,6 @@ Usage of reclaimable-pv-releaser:
     	log to standard error as well as files
   -controller-id string
     	this controller identity name - use the same string for both provisioner and releaser
-  -disable-automatic-association
-    	disable automatic PV association
   -kubeconfig string
     	optional, absolute path to the kubeconfig file
   -lease-lock-id string

cmd/reclaimable-pv-releaser/main.go

@@ -2,7 +2,7 @@ package main
 
 import (
 	"context"
-	"flag"
+
 	controller "github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers"
 	"github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers/releaser"
 	clientset "k8s.io/client-go/kubernetes"
@@ -11,9 +11,6 @@ import (
 )
 
 func main() {
-	var disableAutomaticAssociation bool
-	flag.BoolVar(&disableAutomaticAssociation, "disable-automatic-association", false, "disable automatic PV association")
-
 	var c controller.Controller
 	run := func(
 		ctx context.Context,
@@ -23,7 +20,7 @@ func main() {
 		namespace string,
 		controllerId string,
 	) {
-		c = releaser.New(ctx, client, namespace, controllerId, disableAutomaticAssociation)
+		c = releaser.New(ctx, client, namespace, controllerId)
 		if err := c.Run(2, stopCh); err != nil {
 			klog.Fatalf("Error running releaser: %s", err.Error())
 		}

controller.go

@@ -286,6 +286,16 @@ func (c *BasicController) Requeue(queue workqueue.RateLimitingInterface, old int
 	c.Enqueue(queue, new)
 }
 
+func (c *BasicController) Forget(queue workqueue.RateLimitingInterface, obj interface{}) {
+	var key string
+	var err error
+	if key, err = cache.MetaNamespaceKeyFunc(obj); err != nil {
+		utilruntime.HandleError(err)
+		return
+	}
+	queue.Forget(key)
+}
+
 func (c *BasicController) RunWorker(
 	name string,
 	queue workqueue.RateLimitingInterface,

examples/basic/README.md

@@ -11,11 +11,18 @@ nerdctl -n k8s.io build -t kubernetes-dynamic-reclaimable-pvc-controllers:dev .
 2. Deploy
 
 ```bash
+# Create SC
+kubectl apply -f ./examples/basic/sc.yaml
+
 helm repo add plumber-cd https://plumber-cd.github.io/helm/
 helm repo update
 helm install provisioner plumber-cd/dynamic-pvc-provisioner -f ./examples/basic/values.yaml
 helm install releaser plumber-cd/reclaimable-pv-releaser -f ./examples/basic/values.yaml
 
+# Or - using local
+helm install provisioner ../helm/charts/dynamic-pvc-provisioner -f ./examples/basic/values.yaml
+helm install releaser ../helm/charts/reclaimable-pv-releaser -f ./examples/basic/values.yaml
+
 # Check it came up
 kubectl logs deployment/provisioner-dynamic-pvc-provisioner
 kubectl logs deployment/releaser-reclaimable-pv-releaser
@@ -24,6 +31,12 @@ kubectl logs deployment/releaser-reclaimable-pv-releaser
 3. Test
 
 ```bash
+# Delete SC and see it is forgotten
+kubectl delete -f ./examples/basic/sc.yaml
+kubectl logs deployment/releaser-reclaimable-pv-releaser
+kubectl get events
+
+# Test provisioner
 kubectl apply -f ./examples/basic/sc.yaml
 kubectl apply -f ./examples/basic/pod.yaml
 
@@ -34,9 +47,6 @@ kubectl describe pod pod-with-dynamic-reclaimable-pvc
 # Check provisioner logs
 kubectl logs deployment/provisioner-dynamic-pvc-provisioner
 
-# Check releaser logs
-kubectl logs deployment/releaser-reclaimable-pv-releaser
-
 # Check PV and PVC
 kubectl get pv
 kubectl get pvc
@@ -55,7 +65,6 @@ kubectl get pv
 kubectl apply -f ./examples/basic/pod.yaml
 kubectl describe pod pod-with-dynamic-reclaimable-pvc
 kubectl logs deployment/provisioner-dynamic-pvc-provisioner
-kubectl logs deployment/releaser-reclaimable-pv-releaser
 kubectl delete -f ./examples/basic/pod.yaml
 kubectl logs deployment/releaser-reclaimable-pv-releaser
 ```
@@ -66,4 +75,5 @@ kubectl logs deployment/releaser-reclaimable-pv-releaser
 kubectl delete -f ./examples/basic/sc.yaml
 helm uninstall provisioner
 helm uninstall releaser
+kubectl delete lease provisioner-dynamic-pvc-provisioner releaser-reclaimable-pv-releaser
 ```

examples/basic/sc.yaml

@@ -2,6 +2,8 @@ kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
   name: reclaimable-storage-class
+  annotations:
+    reclaimable-pv-releaser.kubernetes.io/controller-id: dynamic-reclaimable-pvc-controllers
 provisioner: rancher.io/local-path
 reclaimPolicy: Retain
 volumeBindingMode: WaitForFirstConsumer

examples/jenkins-kubernetes-plugin-with-build-cache/README.md

@@ -6,6 +6,8 @@ kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
   name: jenkins-maven-cache
+  annotations:
+    reclaimable-pv-releaser.kubernetes.io/controller-id: dynamic-reclaimable-pvc-controllers
 provisioner: kubernetes.io/aws-ebs
 parameters:
   type: gp2
@@ -16,6 +18,8 @@ kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
   name: jenkins-golang-cache
+  annotations:
+    reclaimable-pv-releaser.kubernetes.io/controller-id: dynamic-reclaimable-pvc-controllers
 provisioner: kubernetes.io/aws-ebs
 parameters:
   type: gp2