Use xxx as storage backend for the orchestrator
-
Status: superseded by ADR7
-
Deciders:
-
Date:
Technical Story: == Deprecation Notice This ADR has been superseded by ADR7, which decided to stop development on the orchestrator for now and use the kube-apiserver instead. As the kube-apiserver exclusively supports etcd as backend provider there is no decision to document at this time.
This ADR reflects the current state of dicussion at the time of approving ADR7 and should not be considered complete!
Context and Problem Statement
The orchestrator will need some form of persistent storage backend, for which a decision on the technology to be used has to be taken. Our usage of this storage will most probably be extremely simple, even if a SQL database is chosen, the expectation is that it will be used fairly similar to a key value storage.
Decision Drivers
-
Availability of libraries for chosen programming language for the orchestrator
-
How established is the backend at potential customers, will we need to deploy it?
Decision Outcome
etcd
-
Good, because etcd is used by Kubernetes
-
Likelyhood that it is already deployed
-
Expertise with etcd by Kubernetes admins can be reused
-
-
Good, because it offers watch functionality
-
Good, because it offers consensus mechanisms
-
Bad, because it has a hard size limit
-
Bad, because it does not work well with large numbers of requests
ZooKeeper
-
Good, because it is well established and unterstood
-
Good, because it offers watch functionality
-
Good, because it offers consensus mechanisms
-
Bad, because it offers no real benefit over etcd
-
Bad, because it is known to have trouble with high volume of changes
SQL Database
-
Good, because expertise and processes for some form of database will be present at pretty much any customer
-
Backup
-
HA
-
-
Good, because deploying in integrated test/dev environment is easy with sqlite
-
Bad, because we would need to potentially support multiple database vendors
-
Postgres
-
MS Sql
-
Oracle
-
…
-