Perses Pod Management - Deployment vs. StatefulSet

[ibakshay]

I've noticed that the Perses Pod is managed by a Deployment rather than a StatefulSet within the perses-operator. Is this by design?

My concern stems from the observation that the Perses Pod is managed by a StatefulSet in the perses/helm-charts repository: perses/helm-charts.

This raises two questions:

1. Why is there a discrepancy in pod management between the perses operator and the Helm chart?
2. What state is being stored in the StatefulSet managed by the Helm chart?

[jgbernalp]

Before the operator existed, we had helm charts, maybe thats the reason of the discrepancy. From the operator view, one or many instances of Perses runs on a deployment as the state (dashboards, datasources, etc) should be handled in a different storage layer, in the operator case CRs are being used. I think the helm charts are provided as StatefulSet to include this storage. Any thoughts @nicolastakashi?

[Nexucis]

It's a statefulset because if you are using the filesystem database rather than mysql then the database is in the pod. So you need a statefulset to avoid ripping appart the database.

I think that's why it's like that.

Filesystem database is more used when you want to try quickly Perses. It's not designed for production instance from my opinion.
Perhaps in the helm chart we should drop the possibility to use the filesystem database in favor of mysql and then move to the deployment object

[nicolastakashi]

We’re using StatefulSets primarily for filesystem persistence and the ability to reclaim Persistent Volumes (PVs) using Persistent Volume Claims (PVCs). If users prefer to use an external database like MySQL, we could switch from StatefulSets to Deployments.

However, I believe we should continue supporting local filesystem storage as it reduces friction for users who want to get started with Perses quickly. It also avoids introducing multiple dependencies, making the setup simpler.

Using a local filesystem is usually fine for non-critical environments, such as development or staging, where high availability isn’t required, and some level of downtime is acceptable.

[ibakshay]

Before the operator existed, we had helm charts, maybe thats the reason of the discrepancy. From the operator view, one or many instances of Perses runs on a deployment as the state (dashboards, datasources, etc) should be handled in a different storage layer, in the operator case CRs are being used. I think the helm charts are provided as StatefulSet to include this storage. Any thoughts @nicolastakashi?

@jgbernalp Thank you very much for the explanation. That helps me to connect the dots.

Should we need to include a CRD for other entities like Project, GlobalRole, GlobalRoleBinding, GlobalDatasource...?
I think the all the Global entities should be cluster scoped resources.

Right now, there are only CRDs for PersesDashboard and PersesDatasource

[jgbernalp]

Although the document might need an update. Project and probably the roles and role bindings are supposed to match namespaces and k8s (cluster)roles and (cluster)role bindings. The one probably missing would be the GlobalDatasource

[Nexucis]

Although the document might need an update

yeah totally. We should update this document to reflect how exactly Perses is working in k8s when deployed with the operator.