You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Around 2020 Kubernetes spec introduced the Operator Pattern for creating YAML that can manipulate many different types of cluster resources and include provisions for scaling and adapting to different scenarios automatically. (Capitalizing the O is important, it differentiates between an operator [human who manages the cluster] and the automated spec) Since then development of Operators has followed a similar pattern to Helm charts, providing a simple way to 'install' cluster resources containing specific container images to run as a service. Namely in the wild, a helm chart mainly specifies creating a stateless deployment of a service into an extant cluster, whereas Operators are more often associated with stated applications that include other resources like persistent volume claims e.g.
Presently there exists a Tiled helm chart created by @DiamondJoseph which is useful for provisioning a standard Tiled deployment, however as work on the NSLS-II NEXT-III and N3XTWARE initiatives has commenced we've found use for deploying Tiled on a stateful set and including other resources by default like a Postgres instance, PVC for artifact storage that mounts our institution's NFS, etc.
What is the general consensus on creating a Tiled operator that can be pulled from OperatorHub when needed?
The text was updated successfully, but these errors were encountered:
For context at DLS we're deploying tiled with ArgoCD, temporarily using an umbrella chart to store configuration for DBs/volume claims until they're moved into their own Argo Application as part of an app-of-apps that runs tiled + infrastructure.
Switching the Tiled Helm chart to be a StatefulSet instead of a ReplicaSet is easily done in the Helm chart and something I will probably do sooner rather than later. I believe an Operator could be implemented into our Argo application just as easily as any other Kubernetes resource, so if it turns out to be an easier deployment it'd be simple for us to adopt.
Currently I like having the DB deployed explicitly outside of tiled (i.e. not as a direct dependency of the tiled chart), as we can version the two seperately when DB chart tends to move faster than tiled's- does an Operator allow this? I presume like a Helm chart it can pass down any config.
Around 2020 Kubernetes spec introduced the Operator Pattern for creating YAML that can manipulate many different types of cluster resources and include provisions for scaling and adapting to different scenarios automatically.
(Capitalizing the O is important, it differentiates between an operator [human who manages the cluster] and the automated spec)
Since then development of Operators has followed a similar pattern to Helm charts, providing a simple way to 'install' cluster resources containing specific container images to run as a service. Namely in the wild, a helm chart mainly specifies creating a stateless deployment of a service into an extant cluster, whereas Operators are more often associated with stated applications that include other resources like persistent volume claims e.g.
Presently there exists a Tiled helm chart created by @DiamondJoseph which is useful for provisioning a standard Tiled deployment, however as work on the NSLS-II NEXT-III and N3XTWARE initiatives has commenced we've found use for deploying Tiled on a stateful set and including other resources by default like a Postgres instance, PVC for artifact storage that mounts our institution's NFS, etc.
What is the general consensus on creating a Tiled operator that can be pulled from OperatorHub when needed?
The text was updated successfully, but these errors were encountered: