[CHORE] adding datasources provisioning

[nicolastakashi]

Description

I'm adding the ability to provision datasources when install Perses using helm chart.

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, IGNORE.
• All commits have DCO signoffs.

[Nexucis]

I don't get how Perses will consider the globalDatasource provisioned, since it should go in a specific folder in the database folder

[nicolastakashi]

I don't get how Perses will consider the globalDatasource provisioned, since it should go in a specific folder in the database folder

Actually i'm mounting the configmap under the {{ .Values.config.database.file.folder }}/globaldatasources does it make sense?

I just tested it locally and it worked as expected.
We can add a test for that if you think wdyt?

[Nexucis]

well the issue is that you are also mounting a volume there where the BE can write. Is it still possible to create another globalDatasource ?

[nicolastakashi]

well the issue is that you are also mounting a volume there where the BE can write. Is it still possible to create another globalDatasource ?

Oh now I got it!
If I'm not wrong we just need to ensure securityContext.fsGroup is the same group as the container user and it should work out of the box.

Is there anyway to test it today, since we don't have GlobalDataSource CRUD? @Nexucis

[Nexucis]

Is there anyway to test it today, since we don't have GlobalDataSource CRUD? @Nexucis

Weeelll you have it through the CLI. It's not super easy but it should work :). percli apply -f globaldatasource.json

[nicolastakashi]

Is there anyway to test it today, since we don't have GlobalDataSource CRUD? @Nexucis

Weeelll you have it through the CLI. It's not super easy but it should work :). percli apply -f globaldatasource.json

You're so right 🥲
Maybe the workaround would be use a initcontainer.

But I'll let another question.
If I can manage datasources through helm why I'd like to add it through cli/ui?

[Nexucis]

If I can manage datasources through helm why I'd like to add it through cli/ui?

I think a good way to do it would be through CRDs then.
From my perspective, if you want to have a datasource provisioning, it supposed you still have perses connected to a database which means it can create datasource with the API ( so with a different flow)

[nicolastakashi]

If I can manage datasources through helm why I'd like to add it through cli/ui?

I think a good way to do it would be through CRDs then. From my perspective, if you want to have a datasource provisioning, it supposed you still have perses connected to a database which means it can create datasource with the API ( so with a different flow)

I see your point and I can agree on a certain level, but I see the CRD being part of the Perses operator (under development yet), and the operator will be another option to deploy and manage Perses.

With that in mind, I see this helm chart as an option to deploy and manage Perses without having to manage an operator and all its resources such as CRDs.

After a while of thinking about this, my idea to overcome the read-only file system issue you pointed out is to leverage the Perses CLI as a side-car and leverage the apply command to apply the dashboards without mounting them. volume.

WDT? @Nexucis

[Nexucis]

With that in mind, I see this helm chart as an option to deploy and manage Perses without having to manage an operator and all its resources such as CRDs.

yeah me too. perses-operator shouldn't be mandatory to use perses.

After a while of thinking about this, my idea to overcome the read-only file system issue you pointed out is to leverage the Perses CLI as a side-car and leverage the apply command to apply the dashboards without mounting them. volume.

That could work indeed !

[Nexucis]

🥳