...
Namespaces can be provided with their own volume, one volume per namespace, limited in size , ( i.e 50GB10GB). The programming model should handle this volume as short-lived, hence its limited size as well. Its purpose is to make it efficient for sequences and compositions to access assets faster and easierthan if they were downloaded from an eventually consistent blob storage. The volume is independent of an activation lifecycle. Developers have full control over activations lifecycle. It's up to the developers to manage it, including writing to it, but also cleaning it up.
OpenWhisk's implementation could configure a network file system like NFS, (i.e. AWS EFS), GlusterFS, or others. This volume is mounted on each Invoker host. Each namespace has its own subfolder on that volume, and it can be mounted appropriately into a known path in the action containers that want to make use of it. To simplify the stem-cells management, each action requiring access to such volume may ignore stem-cells; instead, they may go through a cold-start, as if they're blackbox containers.
The diagram bellow shows 2 Invoker Hosts that mount a network file system on /mnt/actions on the host. Action containers mount on Inside the action containers the /tmp the folder is mounted from the host folder corresponding for to the namespace namespace: /mnt/actions/<NAMESPACE>
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...