<p>I have been setting up datasource and dashboard configurations in ConfigMap as following:</p>
<pre><code>kind: ConfigMap
apiVersion: v1
metadata:
  name: datasource-configmap
data:
  datasource.yml: |-
    apiVersion: 1
    datasources:
    - name: prometheus-service
      type: prometheus
      orgId: 1
      access: proxy
      url: http://prometheus:9090/
      basicAuth: false
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: dashboard-configmap
data:
  dashboard.yml: |-
    apiVersion: 1
    providers:
    - name: 'Prometheus'
      orgId: 1
      folder: ''
      type: file
      disableDeletion: false
      editable: true
      options:
        path: /etc/grafana/provisioning/dashboards
  dashboardA.json: |-
    { // }
  dashboardB.json: |-
    { // }
...
...
  dashboardC.json: |-
    { // }
</code></pre>
<p>It works fine till there are certain numbers of lines in the above file, after which it kubectl complains with the following error:</p>
<pre><code>The ConfigMap &quot;grafana-configmap&quot; is invalid: metadata.annotations: Too long: must have at most 262144 bytes
</code></pre>
<p>If I remove long configuration from dashboardC.json, then there are no issues.</p>
<p>How can I overcome this error because the goal is to setup all Grafana datasources and dashboards from a file and not setup on Grafana UI?</p>

maopuppets
<p>Maybe splitting up the dashboard over multiple ConfigMaps could solve the issue. As long as a single definition isn't over <code>262144 bytes</code>. You could then presumable mount them by way of a <a href="https://kubernetes.io/docs/concepts/storage/volumes/#projected" rel="nofollow noreferrer">projected volume</a></p>
<p>Another option would be to mount the files at <code>/etc/grafana/provisioning/dashboards</code> by way of a job container or init container that contains the correct files. Build this container in some CICD setup and you can store your dashboards in a repo.</p>
<p>Maybe mounting an S3 bucket with the daskboards onto the filesystem is an option.</p>
<p>Personally; option 1 looks easiest but prone to failure over time. Option 3 looks overly complex, option 2 seems robust and fairly easy.</p>
