I Declare is not the same as Make It So

Years ago there was a really great TV show. Kirk, Spock, McCoy, Scotty. You know the one. Later it was remade with some characters long forgotten. Except 1. Picard. His trademark ‘make it so’ was the hallmark of a great leader. With this one phrase he could turn his attention elsewhere, knowing that it would happen.

This is also the hallmark of a new world order in computing. Declarative vs Imperative. In a ‘declarative’ world I document the desired state, and it is the job of the system to ‘make it so’. In a declarative world you don’t need to worry about ‘how’, and you don’t need to worry about things later breaking… If they change, the system puts it back. Its a control system, like that PID controller you learned years ago.

In an imperative world, you instruct each step. Install that software, configure that port, etc. You are the controller. If something later breaks, you notice and change it.

OK, we are clear on the concept. Now does it work in practice? Mostly. Where it breaks are things that cannot be updated. Let’s take an example. Let’s say I have a horizontally scalable app. Its beautiful, shards of all shapes and sizes are hanging out. Now, in order to maintain consistency, I need a minimum number online. As I scale it up, that number would change, right? It might be 2/3 of the total online number, something like that.

Enter the humble PodDisruptionBudget. Lets say I use this feature, in conjunction with setting the # of replicas in my StatefulSet.

---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  labels:
    app: COOL
  name: MYAPP
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: COOL

What is one to do here when I follow the law of the declarative world. I set the config the way I want, commit to git and… “The PodDisruptionBudget “master” is invalid: spec: Forbidden: updates to poddisruptionbudget spec are forbidden.” O no. I’m now stuck.

Hmm. I cannot ‘make it so’?