Like the idea :) but doesnt /cache sound like /tmp already? What about var/build / getBuildDir instead?

What are the actual benefits of this change? I mean, there is a cache directory, which is widely used by bundles and even applications. What are the benefits of adding such a new directory, other than putting meta constraints on it, that are no issue right now? What's the intent for this change?

Assuming, that you (as in the framework) are the only one, using the cache directory, is totally wrong to me. There are most likely applications (and probably even bundles) out there, using the cache directory for runtime caching, already.

Anyone "smart enough" would not even use the new tmp directory, because it's already outside of the project directory, e.g. on a RAM disk. Not to say they will be totally different approaches for temporary data management.

What's the "No BC Break" solution of this? Adding a new interface, checking for its existence and falling back to the old behaviour (use cache), while implementing it on the abstract kernel.

I would consider those BC Break, and I'm mentioning them here, because we have all seen this happening already, e.g. with the Form component.

• Adding a new method to the Symfony\Component\HttpKernel\Kernel and rely on the implementation? Will kill apps not even using the abstract class.
• Adding a new method to the Symfony\Component\HttpKernel\KernelInterface would be BC break by definition.

Even requiring to setup the new directory is BC break on the infrastructural level of the framework: You need to change deployment processes, grant access to new directories etc. What are the customer needs for this change?

The benefit would be that the "cache" directory could be mounted as readonly - and that we, the core team, would consider any write attempt there a bug. The "tmp" dir would be the only one with required read+write access, and we could (the community) advertise that the less you put here the better.

About the BC break, it is not required: we could just start by putting the tmp dir inside the cache dir as a first step in 3.4, then (if worth it) move it outside by default in 4.0, for new projects only ideally.

There is at least one blocker: the cache pools, which need runtime write access.

IMO this is significant enough to warrant a consideration: you're trying to make the cache folder read-only, but the cache pool is in your way so you'll move the cache pool out of cache folder. :)

Anyway, this is obviously a misnomer situation: there's different requirements on file-system storage by various subsystems (build-time, run-time) with varying read/write and volatility requirements. For the record, I think having a dedicated tmp folder (volatile runtime data) is a good move. 👍

Linux hier manpage talks about this, took out some more important ones (I'm not proposing to introduce all or even most of these, but it makes sense to see usage patterns):

/var
This directory contains files which may change in size, such as spool and log files.

/var/cache
Data cached for programs.

Volatile runtime data.

/var/lib
Variable state information for programs.

This is where MySQL stores its database files so it's non-volatile runtime data.

/var/lock
Lock files are placed in this directory. The naming convention for device lock files is LCK.. where is the device's name in the file system. The format used is that of HDU UUCP lock files, that is, lock files contain a PID as a 10-byte ASCII decimal number, followed by a newline character.
/var/log
Miscellaneous log files.
/var/run
Run-time variable files, like files holding process identifiers (PIDs) and logged user information (utmp). Files in this directory are usually cleared when the system boots.
/var/spool
Spooled (or queued) files for various programs.
/var/tmp
Like /tmp, this directory holds temporary files stored for an unspecified duration.

BTW segmenting files by when, how and by whom they are being written also play nicely with established runtime environments such as SELinux (used in most/all RedHat products like RHEL/CentOS, Openshift) where you have "contexts" in which certain paths (files properly labeled, to be exact) are accessible.

Free-for-all type of situation is not really great.

Are there any new thoughts or is there any progress on this issue? I need to find a way to deploy a "hot build cache" to reduce warmup time of my Symfony applications. I'm running background tasks on Azure Functions and I suffer from long warmup times when scaling out to multiple instances.

@smoelker: It does at least seem to work if you point the cache pools and the profiler to alternative directories. It's not hard to try out, so you should see what problems you run into (if any).

I have a very simple application in which i ship the container with the application in /usr/share/myapp, and then point the cache and profiler to directories in /var.

NOTE tho, that cache:clear will not clear those, so you have to use the cache:pool commands to clear the cache pools, and rm -rf the profiler files.

Naming confusion aside, having a well-defined boundary between build-time files created when “warming the cache” and files that can be written at runtime would be a massive, very welcome improvement for deploying to modern hosting stacks.

For example, when running on AWS Lambda, the filesystem is read-only. There is a writeable /tmp directory that can be used at runtime, but there's no officially supported way to deploy pre-warmed files there. Having the distinction between the two directories would make this trivial to use.

I have opened #36515 to try to move this topic forward. Solving this would make Symfony ready for AWS Lambda and other serverless platforms (like Azure Functions as well).

I'm not sure if I should give input here or at #36515 but I'd argue that indroducing a new "imutable cache" would be less prone to backwards compatibility issues and can be named better.

Something like getBuildDir() which returns a directory where files can be generated during cache warmup, like the container, but must not be modified during normal runtime.

Existing code relying on the cache dir will continue to work because the guarantee of getCacheDir won't change. Any existing bundle/project that relies on the cache dir must opt-in into the new immutable build cache instead of opt-out like it would be the case if we'd add a temp dir and change the cache dir definition.

I think the problem is mostly naming, yes. Currently it's said the container is "cached", which is not really true, it's prebuilt. Cache implies volatility which isn't compatible with immutability obviously, so having "cache" be immutable is counter-intuitive to say the least, as I've noted before.

Those are very good points!

Introducing a getBuildDir() would make complete sense, and would be even easier to explain and keep BC.

I'm happy to follow that route.

Closing to focus the discussion on the open PR instead.