Closed vladimir-babichev closed 5 months ago
@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.
@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.
Hi all, just a gentle bump.
@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
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
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?
In my fridge configmap I have the following options set
database:
path: /data/frigate.db
I do the same as @onedr0p
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
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?
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?
Kludge to get persistence of clips/recordings to work without modifying the chart:
persistence:
data:
enabled: true
extraVolumeMounts:
- name: data
mountPath: /media
subPath: frigate
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
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
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).
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?
+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
+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.
The above extraVolume
and extraVolumeMounts
solutions break in the latest chart 7.3.0
. When not specifying media persistence an emptyDir
is created: https://github.com/blakeblackshear/blakeshome-charts/compare/frigate-7.2.0...frigate-7.3.0#diff-fab55a2ebafe0c123d8ab5d0ba00ee633f7fecb3ca7f7e145f5bed59b382ac13R154
And you now cannot avoid mounting a volume media
to /media
: https://github.com/blakeblackshear/blakeshome-charts/compare/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.
This PR addresses #6