Update PVC mount point

[vladimir-babichev]

This PR addresses #6

[billimek]

@vladimir-babichev what do you think about updating this PR to add the media PVC and associated files in addition to the existing data PVC & files?

This way, the change will not be breaking for any current users of the chart, and I can see a use-case where having both would be useful.

[vladimir-babichev]

@billimek In general I don't mind, but can you point me where /data folder is used? This folder is always empty in my deployment and I didn't find any references to it in configuraiton.

[vladimir-babichev]

Hi all, just a gentle bump.

[onedr0p]

@billimek In general I don't mind, but can you point me where /data folder is used? This folder is always empty in my deployment and I didn't find any references to it in configuraiton.

In my /data folder I have:

frigate.db  frigate.db-shm  frigate.db-wal

[rmarku]

Just deployed the chart and configured some cams. My data is empty and in medi I have:

root@frigate-7f8dc76dc8-rvpv9:/opt/frigate# find / -iname "frigate.db*"
/media/frigate/clips/frigate.db-shm
/media/frigate/clips/frigate.db
/media/frigate/clips/frigate.db-wal

[vladimir-babichev]

According to docs and application code frigate uses /media folder as default storage location.

@onedr0p @billimek would you mind sharing helm values and the helm chart version you use?

[onedr0p]

In my fridge configmap I have the following options set

database: 
  path: /data/frigate.db

[billimek]

I do the same as @onedr0p

[vladimir-babichev]

Thank you @onedr0p and @billimek. If I read it correctly, both of you applied custom configuration to override the default database location.

The general rule of thumb that I follow in my practice, is helm chart should complement the application it is designed for and incorporate its default behaviour. Any custom modifications are always welcomed but should be managed with a help of the values file.

If that is fine with you, I suggest we update charts default behaviour to set /media as default data location and bump charts major version. To make this work for your setups, you may require to add a couple of extra parameters to values.yaml:

extraVolumes:
  - name: data
    persistentVolumeClain:
      claimName: frigate-data
extraVolumeMounts:
  - name: data
    mountPath: /data

[maxirus]

Ran into this issue as well since init attempts to modify permissions of /media/frigate which breaks setting things like securityContext.fsGroup.

I would 2nd @vladimir-babichev's comments that the Helm Chart should closely follow/align with the Project defaults. Update the major version to accept this change as it would (potentially) break existing deployments?

[jhoblitt]

I am puzzled as to why the chart is mounting a volume as /data with no default usage. Even if the .db is manually relocated under /data, the clips and recordings are still written under /media.

What is required to get this PR merged?

[jhoblitt]

Kludge to get persistence of clips/recordings to work without modifying the chart:

persistence:
  data:
    enabled: true
extraVolumeMounts:
  - name: data
    mountPath: /media
    subPath: frigate

[rssnyder]

My config for persisting captures:

extraVolumes:
  - name: media
    persistentVolumeClaim:
      claimName: nfs-frigate
extraVolumeMounts:
  - name: media
    mountPath: /media

where nfs-frigate is an existing NFS PVC

[gaffneyd4]

I ran into this weirdness as well and used these two comments to address:

In my fridge configmap I have the following options set

database: 
  path: /data/frigate.db

My config for persisting captures:

extraVolumes:
  - name: media
    persistentVolumeClaim:
      claimName: nfs-frigate
extraVolumeMounts:
  - name: media
    mountPath: /media

where nfs-frigate is an existing NFS PVC

[SchoolGuy]

Ping on this PR. This hit me today and I was completely baffled why all my events and recordings are gone after each day (running openSUSE MicroOS restarts the host every day).

[thurcombe]

hello, what is happening with this? been open for years now, all clips are lost on a pod restart, given that /media is where the clips are supposed to be, surely the chart should provide for this? I see a number of issues open so it would be nice to get a clear picture on where this is currently at?

[potchin]

+1 on this, having the app and the helm chart disagree about where the app state lives is pretty bad. Bump the major version and merge this already

[XtremeOwnageDotCom]

+1 on this, having the app and the helm chart disagree about where the app state lives is pretty bad. Bump the major version and merge this already

@billimek what is the status on this PR?

In the current state, deploying a fresh chart, and enabling persistence

persistence:
  data:
    # -- Enables persistence for the data directory
    enabled: true
    storageClass: local-storage
    existingClaim: frigate
    subPath: data

    # -- [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) to use for the PVC
    accessMode: ReadWriteOnce

    # -- size/capacity of the PVC
    size: 3.4Ti

    # -- Do not delete the pvc upon helm uninstall
    skipuninstall: true

Will yield a completely broken installation, as nothing not be persisted.

As the comments in the example values.yaml says, # -- Enables persistence for the data directory

My assumption would be, this means my recordings and data should be stored there. However, that would not be the case, and the documentation for this helm chart does not mention this.

As a matter of fact, the example values.yaml does not mention anything other then enabling persistence.

By default, even the database appears to be stored in /media. Using a completely stock-install, will mount the default persistence in /data, however, there is nothing actually stored here.

Is, the expectation for new years to install this helm chart, reboot their system after a few months, and then get angry at frigate because all of their recordings and data are now missing? Or- can we make progress on this PR which was submitted soon to be three years ago.

If nothing better, I can go submit a PR, to at least notify users to add this piece of duct-tape into their values.

[rssnyder]

The above extraVolume and extraVolumeMounts solutions break in the latest chart 7.3.0. When not specifying media persistence an emptyDir is created: frigate-7.2.0...frigate-7.3.0#diff-fab55a2ebafe0c123d8ab5d0ba00ee633f7fecb3ca7f7e145f5bed59b382ac13R154

And you now cannot avoid mounting a volume media to /media: frigate-7.2.0...frigate-7.3.0#diff-fab55a2ebafe0c123d8ab5d0ba00ee633f7fecb3ca7f7e145f5bed59b382ac13R113-R114

You now need to get rid of your extra mounts/volumes and pass your PVC to the media persistence value:

persistence:
  media:
    enabled: True
    existingClaim: media

I think this PR can be closed now.