[BUG] Using a leading / in output_path breaks dashboard restore

[arnecls]

When setting output_path to a path starting with /, like /backup, the dashboard restore will complain about a / being used in the folder name.

To Reproduce

Use a config like this

    contexts:
       backup:
         output_path: '/backup'

Run gdg backup dashboards download.
If you then run gdg backup dashboards upload --skip-confirmation, an error will be shown "path separator not supported in folder name".

If you omit the / from output_path the same process works.

Expected behavior

It should not matter if an absolute or relative path is set for output_path.

Desktop (please complete the following information):

• GDG Version: 0.7.1
• Grafana Version: 11.1.0

[safaci2000]

Interesting, thanks for reporting that. Yeah that definitely should work. I'll try to reproduce this and get a fix out, I don't imagine it should be too terrible.

[safaci2000]

Hmm, okay. I can't seem to reproduce this same behavior. I think there's other factors involved beyond the path name.

Here's my config

gdg t ctx show

---testing:
storage: ""
url: http://localhost:3000
token: ""
user_name: admin
password: admin
organization_name: Main Org.
watched_folders_override: []
watched: []
connections: null
user:
    random_password: true
    min_length: 8
    max_length: 20
dashboard_settings:
    nested_folders: false
    ignore_filters: true
output_path: /tmp

gdg version

2024-12-17 15:07:06 INF Build Date: 2024-09-11T20:25:11Z
2024-12-17 15:07:06 INF Git Commit: 5e5f2a2ef64beb391bd47f7ff4d641ca515454c4
2024-12-17 15:07:06 INF Version: v0.7.1
2024-12-17 15:07:06 INF Go Version: go1.23.0
2024-12-17 15:07:06 INF OS / Arch: darwin arm64

gdg t devel srvinfo

2024-12-17 15:09:35 INF  Database=ok
2024-12-17 15:09:35 INF  Commit=5b85c4c2fcf5d32d4f68aaef345c53096359b2f1
2024-12-17 15:09:35 INF  Version=11.1.0

I don't think the behavior would change based on the grafana version but I'm running the same exact version.

gdg b dash download --skip-confirmation

2024-12-17 15:10:12 INF Running Sanity Check of Organization Membership
2024-12-17 15:10:12 INF Downloading dashboards with  nested=false
2024-12-17 15:10:12 INF Downloading dashboards for context Organization="Main Org." context=testing
┌───────────┬────────────────────────────────────────────────────────────────────────┐
│ TYPE      │ FILENAME                                                               │
├───────────┼────────────────────────────────────────────────────────────────────────┤
│ dashboard │ /tmp/org_main-org/dashboards/General/bandwidth-dashboard.json          │
│ dashboard │ /tmp/org_main-org/dashboards/General/bandwidth-patterns.json           │
│ dashboard │ /tmp/org_main-org/dashboards/General/individual-flows-per-country.json │
│ dashboard │ /tmp/org_main-org/dashboards/General/individual-flows.json             │
│ dashboard │ /tmp/org_main-org/dashboards/General/loss-patterns.json                │
│ dashboard │ /tmp/org_main-org/dashboards/General/other-flow-stats.json             │
│ dashboard │ /tmp/org_main-org/dashboards/General/science-discipline-patterns.json  │
│ dashboard │ /tmp/org_main-org/dashboards/General/top-talkers-over-time.json        │
│ dashboard │ /tmp/org_main-org/dashboards/Ignored/latency-patterns.json             │
│ dashboard │ /tmp/org_main-org/dashboards/Other/dashboard-makeover-challenge.json   │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-analysis.json                  │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-data-for-circuits.json         │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-data-for-projects.json         │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-data-per-country.json          │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-data-per-organization.json     │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flow-information.json               │
│ dashboard │ /tmp/org_main-org/dashboards/Other/flows-by-science-discipline.json    │
└───────────┴────────────────────────────────────────────────────────────────────────┘

as it stands I can't reproduce the same behavior, can you share the rest of your configuration, excluding tokens/passwords etc. I even tried to enable the nested_folders to true vs false which changes a recent behavior that was introduced in 0.7.2 and I'm not able to reproduce this bug.

[safaci2000]

Also, I tried /tmp, /tmp/data/ and '/tmp' to have a quoted version

[arnecls]

🤔 weird. Here's my config for comparison (I redacted some private information)

    context_name: 'backup'

    storage_engine:
      gcs:
        kind: 'cloud'
        cloud_type: 'gs'
        bucket_name: '***'
        prefix: 'grafana-master'

    contexts:
      backup:
        storage: 'gcs'
        organization_name: 'trivago'
        output_path: 'backup' # <--- this

        user_name: '***'
        password: '***'

        url: 'http://grafana-operator-grafana-service.grafana-operator:3000'

        dashboard_settings:
          ignore_filters: true
          nested_folders: false
          debug: true

GDG is running as a cronjob where the output_path is mounted as a PVC.
When I switch this (and the mount) to /backup it breaks.

Here's the cronjob definition

apiVersion: batch/v1
kind: CronJob
metadata:
  labels:
    helm.sh/chart: grafana-operator-package-5.6.1
  name: grafana-backup
  namespace: grafana-operator
spec:
  concurrencyPolicy: Forbid
  failedJobsHistoryLimit: 1
  schedule: 0 * * * *
  successfulJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 0
      completions: 1
      template:
        spec:
          containers:
            - args:
                - -c
                - /etc/config/gdg.yaml
                - backup
                - dashboards
                - upload
                - --skip-confirmation
              image: ***/ghcr-io-mirror/esnet/gdg:0.7.1
              name: grafana-backup-dashboards
              resources:
                limits:
                  memory: 256Mi
                requests:
                  cpu: 100m
                  memory: 256Mi
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - ALL
                readOnlyRootFilesystem: true
                runAsGroup: 65532
                runAsNonRoot: true
                runAsUser: 65532
              volumeMounts:
                - mountPath: /etc/config/
                  name: config
                  readOnly: true
                - mountPath: /app/backup # <--- this
                  name: scratch
                  readOnly: false
          restartPolicy: Never
          serviceAccountName: grafana-operator-grafana-sa
          volumes:
            - configMap:
                defaultMode: 0444
                name: grafana-backup
              name: config
            - emptyDir: {}
              name: scratch

[safaci2000]

Ah, the cloud pattern uses a different code path then what I tested. I'll see what I can setup.

Just to clarify a few things, since I'm not that familiar with K8s Cronjobs. You're mounting a folder named /app/backup locally but you don't expect anything to be written there.

Based on your GDG config you'd expect the gs backup to be in gs://mybucket/backup/grafana-master/<standard gdg naming paths>/

If you run the backup without the / in the output path, does it work as expected? As far as your expectations? Basically what i'm trying to get to, is the issue mainly that the / is included shouldn't break, but 'bucket' is equivalent '/bucket' as far as behavior, or if there's a large issue you're seeing.

---

Also, Mind if I steal your K8s cron example? someone was asking about a kubernetes CronJob example a while back I never got around to looking into.