Labs Alternatives

labs reviews and mentions

• A common theme with database operators that bugs me...
  2 projects | /r/kubernetes | 31 Jul 2021

  Cool! I would be interested in knowing how it goes. From experience one thing I would like to mention is to give due consideration on how you model the Spec properties of your Custom Resource. Say, for user creation, you could take just user names as input or you could take the actual command to create user as input. If you do latter then the Operator essentially just acts like a pass-through for running whatever commands that are provided in the Spec. While this might seem appealing, especially since you are targeting multiple different databases, it is also problematic since such an approach is not 'declarative'. For a purely declarative approach you want to just take the names of the users to be created as input and not the actual command. The command should be part of the Operator's implementation. Advantage of such a declarative approach is that if say the Custom Resource users were to re-apply a Custom Resource, then your Operator will be easily able to determine if from the provided usernames, which ones already exist in the underlying database and which ones need to be added new. Btw, the reason I say from experience is because we made this mistake while implementing our Postgres Operator. Here is an example Custom Resource YAML from our Operator for reference - https://github.com/cloud-ark/labs/blob/master/postgres-crd-v2/artifacts/examples/add-user.yaml . Originally we were taking complete commands as input and ran into problem when determining the diffs.