@kapa.ai mount emptydir on /tmp in workload pods

Based on the knowledge sources provided, it seems you are looking to mount an

emptyDir

volume on

/tmp

in your workload pods. Here's an example of how you can do this in your Kubernetes pod configuration:

yaml apiVersion: v1 kind: Pod metadata:   name: my-pod spec:   containers:   - name: my-container     image: my-image     volumeMounts:     - name: tmp-volume       mountPath: /tmp   volumes:   - name: tmp-volume     emptyDir: {}

In this configuration, an

emptyDir

volume named

tmp-volume

is created and mounted into the

my-container

at the

/tmp

path. The

emptyDir

volume is initially empty and data written to it is stored on the node that the pod runs on. However, please note that the data in an

emptyDir

volume is safe across container crashes but it can be lost if the pod is removed from the node for any reason. If your pod is deleted and recreated (for example, through a deployment), the data in the

emptyDir

is deleted forever. For more specific use cases or configurations, you might need to adjust the configuration accordingly. For instance, in the context of Airbyte, additional volumes and volume mounts are often configured for specific containers such as

webapp

,

temporal

, etc., as seen in the [Github issues](https://github.com/airbytehq/airbyte/issues/38461) related to Airbyte's Kubernetes deployment. Please ensure to adjust the configuration according to your specific requirements and the guidelines provided by your platform or DevOps team.

@kapa.ai I mean on the pods that are created by the workload launcher

A message from kapa.ai

In the context of Airbyte, the workload launcher creates pods for various tasks such as checking connections, discovering schemas, reading and writing data. However, the knowledge sources provided do not contain specific information on how to mount an

emptyDir

volume on

/tmp

in the pods created by the workload launcher. The configuration of these pods is managed internally by Airbyte and may not be directly accessible or modifiable via Kubernetes manifests. The configuration of these pods is likely defined in the Airbyte's codebase, specifically in the Java classes that handle the creation and management of Kubernetes resources. If you need to customize the configuration of these pods, such as adding volume mounts, you may need to modify the Airbyte's source code or use some form of runtime configuration if supported by Airbyte. However, this would require a good understanding of Airbyte's codebase and may not be recommended without guidance from the Airbyte team. For more specific guidance, I would recommend reaching out to the Airbyte community through their [discussion forum](https://discuss.airbyte.io/) or [Github issues](https://github.com/airbytehq/airbyte/issues). They may be able to provide more specific guidance or feature requests to support your use case.