Skip to content

[Question] Isn't making /var/cache read-only ironic? #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
lukasz-zaroda opened this issue Sep 3, 2017 · 4 comments
Closed

[Question] Isn't making /var/cache read-only ironic? #144

lukasz-zaroda opened this issue Sep 3, 2017 · 4 comments

Comments

@lukasz-zaroda
Copy link

I was making myself up to date with Symfony 4, and here Fabien wrote this:

var/cache/ should now only be used to store long term cached contents like compiled container files, compiled translations, or Doctrine proxies. No temporary files. Basically, anything stored under var/cache should have a warmup class able to generate the cache files. Files that should never be updated after deployment to allow for read-only filesystems.

First thought:

var
read only

I didn't find anyone complaining so I decided to write this. Isn't it a problem? By making var/cache read-only aren't we introducing a new, important type of code - compiled code, which deserves its own directory, like build for example? Maybe that directory could also contain CSS compiled from SASS in the long run and such? This directory could be read-only and be build only once before deploying the app.

I'm not suggesting that it should be the case, just asking what the community thinks, because I'm curious.
@javiereguiluz
Copy link
Member

@lukasz-zaroda I understood this as "var/cache/" is read-only for you, dear developer, but it's a read-write dir for Symfony. But as you said, the "read-write" part is tricky, because you only write once, during app bootstrap/compilation, and read that forever. So, creating a different dir for this, as you propose, could make sense.

@Pierstoval
Copy link
Contributor

Maybe something could be done during container compilation: separate "forever" directories and "maybe could be updated" ones.

For example, templates can be compiled and saved by the templates cache warmer and saved forever, because it finds every template in your app, and you're never likely to create templates on-the-fly and save them in cache at runtime.

Contrary to application cache (the default cache.app service) which is using a filesystem adapter, this is used for application cache and may need invalidation, so it needs read AND write rights.

Is there any statistics/documentation about the things that are warmed-up by Symfony and that are 100% sure to be fixed in time (until next deploy)?

@nicolas-grekas
Copy link
Member

see symfony/symfony#23354

@fabpot
Copy link
Member

fabpot commented Feb 19, 2018

Closing as this is not related to Flex and @nicolas-grekas referenced an issue discussing the matter on symfony/symfony.

@fabpot fabpot closed this as completed Feb 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fabpot @javiereguiluz @nicolas-grekas @lukasz-zaroda @Pierstoval