-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Feature] App Engine Support #9238
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.
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
Comments
Do I see it correctly that one needs to use memcache for caching purposes in Google App Engine? |
One must override |
It is possible, symfony has a warmup cache so you only need to run |
@Baachi Unfortunately, the cache contains absolute paths. |
@GromNaN Ah right, didn't see that. |
Google provide a stream wrapper for Google Cloud Sorage. The cache directory can be overridden on the Kernel class. // ...
class AppKernel extends Kernel
{
// ...
public function getCacheDir()
{
return 'gs://bucket_name/'.$this->environment.'/cache';
}
} |
@GromNaN I've tried this -- the local SDK doesn't allow you to access the gs buckets. When running on a deployed production version, symfony tries to output the cache to the bucket and runs into the |
This is not only an App Engine issue, but a serious problem for deploying to enviroments without filesystem write-access generally. I need to prepare (on a different machine) a package that needs to be ready for use in production. |
there is this http://www.ideato.it/planet-ideato/symfony2-su-google-app-engine/ but not sure how they handle this issue |
A quick list of functions used by Symfony that are permanently disabled on GAE:
|
The caching issue can be solved by using stream wrapper from gaufrette (https://github.com/KnpLabs/Gaufrette) and setting cache dir to |
So are symfony apps just not deployable on google app engine? I am stuck on the tempnam() issue right now. This sucks! |
@greywire not yet, Symfony does not run on GAE as of today. @fabpot is looking into it, I think the approach would be as follows: 1 - remove disabled functions calls from symfony/symfony |
probably i believe the hardest will be symlink() and proc related (I wonder how far can we go without running into proc errors on Symfony for a regular app) |
Are there modules to avoid or workarounds or is this a problem thats ingrained in the core of symfony? I might have to switch to another framework if this is something too difficult to fix in the very near term.. |
@greywire is ingrained 👶 but we are working on it |
Are the proc_* functions used in the core of symfony? What for? It seems like the filesystem issues could be easily fixed as mentioned with a stream wrapper. I'm looking for any quick, dirty hack or if I can eliminate some non essential functionality to get going... |
ref #9483 having some problems after solving some issues with GAE |
Has there been any progress on this? I'm interested in running Symfony on GAE. |
…k on Google App Engine (micheleorselli) This PR was submitted for the master branch but it was merged into the 2.3 branch instead (closes #9784). Discussion ---------- [HttpFoundation] Removed ini check to make Uploadedfile work on Google App Engine | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes related to #9238 Commits ------- ecb6481 removed ini check to make uploadedfile work on gae
+1 I am also interested in running Symfony on GAE and other cloud services. This is a huge limitation of Symfony that prevents it from being used on all Platform as a Service environments that do not provide a writeable file system. |
…tainer (fabpot) This PR was merged into the 2.3 branch. Discussion ---------- [HttpKernel] removed absolute paths from the generated container | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | first step to resolve #6484, #3079, and #9238 | License | MIT | Doc PR | n/a This PR converts absolute paths to relative ones in the dumped container. The code is a bit "ugly", but it gets the job done and I'm not sure that there is a more elegant way without breaking everything. Commits ------- c1450b4 [HttpKernel] removed absolute paths from the generated container
I just found a problem with the translations bundle and google app engine, i wanted to install silex and a basic form, with default form layout.. The problem is the default form layout uses translations for the labels.. And as far i can see both in the code and in the doc, http://silex.sensiolabs.org/doc/providers/translation.html, xliff is added as a default, and that will result in a call to the tempnam() function which is quite bad.. Its called in parseFile, i have fixed the problem with just return a single xml document.. but would like to be able to disable xliff support in some way.. Can it be not default with xliff, or will it be possible to remove a loader? |
@hollodk looks like GAE guys are going to implement |
Maybe this can be used as a temporary workaround to Symfony 2 requiring write access to file system? |
…e generated container (nicolas-grekas) This PR was merged into the 2.3 branch. Discussion ---------- [DependencyInjection] make paths relative to __DIR__ in the generated container | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #6484, #3079, partially #9238, #10894, #10999 | License | MIT | Doc PR | n/a This is an alternative approach to #10999 for removing absolute paths from the generated container: instead of trying to fix the container file after it has been dumped, telling to the PhpDumper where its output will be written allows it to replace parts of strings by an equivalent value based on `__DIR__`. This should be safe, thus the PR is on 2.3. Commits ------- edd7057 [DependencyInjection] make paths relative to __DIR__ in the generated container
What is the current state of this feature request? Is Google App Engine supported, and if not, what needs to be done to make it Symfony 2 compatible with GAE? |
This has now been fixed (well a couple of months ago). |
GAE now supports the tempnam() and sys_get_temp_dir() functions : https://cloud.google.com/appengine/docs/php/#tempnam_and_sys_get_temp_dir_support |
Is there anything missing for GAE support? |
@jakzal yes it lacks at least some documentation (can be more general thant just GAE as Heroku or deployments on containers with ready only code can be in the scope too). I think it can work BTW even if a little tricky at the moment. For example we can't warmup the entire sf2 cache prior to deploy an app (or I have no idea how to do that). It would be cool to ensure that sf2 cache has no writes during the entire life of a deployed application. |
@shouze Could be worth adding an article to the Deployment section of the Symfony cookbook. Do you mind opening an issue over there or maybe even better start a pull request? |
Can someone try to setup a Symfony app on Google App Engine (and write a bit of doc about it)? |
@nicolas-grekas ok so the whole sf2 cache can be warmup from now in 1 pass? If you tell me how to accomplish that... I'm very interested! |
I have published two packages https://github.com/caxy/AppEngineBundle and https://github.com/caxy/AppEngineBridge and am updating the documentation on the bundle (which has some helpful features for integrating with GAE users) before this weekend. Also note that Google has published a fork of the standard edition 2.3 https://cloud.google.com/appengine/docs/php/symfony-hello-world?hl=en |
Symfony should work fine on Google AppEngine now. It there are some problems, specific issues should be created instead of using this old and generic one. |
Since it is not possible to write to the filesystem in Google App Engine, Symfony is unusable, as it has to write out its class maps / cache (and doctrine with its proxy classes) to a directory on the filesystem.
It's also possible that I missed something in the documentation that would allow me to circumvent this issue, but as of now, there doesn't seem to be a way to do this.
The text was updated successfully, but these errors were encountered: