Open howardho-flockfreight opened 1 year ago
We encounter a similar issue. Only noticed it because the cluster node where the operator runs ran out of ephemeral storage and evicted the pod. Seems also be related to #164 as the operator seems to be very verbose.
Your environment
Operator Version: 1.5.0
Connect Server Version: 1.5.1 (from yaml image: 1password/connect-api:1.5.1 )
Kubernetes Version: "v1.23.12-gke.1600"
What happened?
Over time we've seen the disk usage footprint of our onepassword-operator increase linearly. This seems to correlate with usage? After investigating we see that this under /home/opuser/.op/data
opuser@onepassword-connect:~/.op/data$ ls -lrth total 17G drwx------ 2 opuser opuser 4.0K Dec 22 20:49 files -rw-r--r-- 1 opuser opuser 32K Jan 9 18:15 1password.sqlite-shm -rw-r--r-- 1 opuser opuser 17G Jan 9 18:15 1password.sqlite -rw-r--r-- 1 opuser opuser 4.0M Jan 9 18:15 1password.sqlite-wal
I'm not sure what the 1password.sqlite is storing, perhaps access logs? but I wouldn't expect this large growth.
What did you expect to happen?
sqlite grows with usage of passwords accessed not necessarily with count of access?
Steps to reproduce
We deploy the one password connect/operator and use it, and see the growth over time.
Notes & Logs