At present, gitops-engine (and consumers of gitops-engine API) use /dev/shm to store temporary files that are passed to kubectl, such as manifests and cluster credentials. The temp directory logic can be found within pkg/utils/io/io.go.
One disadvantage of this is that since /dev/shm is backed by RAM, it has limited size. For many use cases this is not an issue, however, when concurrently deploying to a large number of Kubernetes clusters, or deploying large k8s manifests, /dev/shm can run out of disk space.
One option is that we could just move to using /tmp, rather than /dev/shm. But, it appears that /dev/shm was chosen intentionally to ensure that sensitive data (such as credentials) are kept off disk (absent disk caching of memory).
Thus, rather than moving to use /tmp, I propose instead allowing API consumers to optionally use a different path, which can then by enabled by API consumers (for example, Argo CD configmap value or env var)
I've also been tackling this problem by reducing the leaking of files into /dev/shm. You can see that work below.
Related issues:
In 'ManageResources' and 'runResourceCommand', temporary files written to '/dev/shm' may not be cleaned up, in rare cases
At present, gitops-engine (and consumers of gitops-engine API) use
/dev/shmto store temporary files that are passed to kubectl, such as manifests and cluster credentials. The temp directory logic can be found withinpkg/utils/io/io.go.One disadvantage of this is that since
/dev/shmis backed by RAM, it has limited size. For many use cases this is not an issue, however, when concurrently deploying to a large number of Kubernetes clusters, or deploying large k8s manifests,/dev/shmcan run out of disk space.One option is that we could just move to using
/tmp, rather than/dev/shm. But, it appears that/dev/shmwas chosen intentionally to ensure that sensitive data (such as credentials) are kept off disk (absent disk caching of memory).Thus, rather than moving to use
/tmp, I propose instead allowing API consumers to optionally use a different path, which can then by enabled by API consumers (for example, Argo CD configmap value or env var)I've also been tackling this problem by reducing the leaking of files into
/dev/shm. You can see that work below.Related issues: