I upgraded my google app-engine to high replication data-store. and now I only see an old version of my site.
When I try to upload my local files using appcfg.py I get the error that python27 is only supported for apps using HRD. But I have HRD. If I go back to an earlier version of python I get the error I need to upgrade to python 27. It is a vicious circle.
I can see my site perfectly using localhost:8080 and it is current, But I have no way of uploading my site!
The app-id of your upgraded HRD version (say newappid) is different from the app-id of the previous M/S version (say oldappid) -- although all accesses to oldappid.appspot.com are being aliased to go to newappid.appspot.com instead.
But the application: line in your app.yaml needs to be newappid; the symptoms you report are those you would observe if that application: line was oldappid instead. Is this indeed the case...?
Related
I have a Django application deployed in Heroku, it has been deployed for months without any issue. Deployments today are suddenly failing saying Heroku doesn't support Python 3.6.10, only 3.6.11 (closest one to 3.6.10)
I have not specified a version anywhere in my app so I can only assume Django defaults to 3.6.10 or Heroku previously did, but they have abruptly stopped supporting it now.
Are there any risks in setting 3.6.11 in my runtime file so my builds work? Is there any reason it defaults to 3.6.10?
The app is in use heavily and Heroku support is awful unless you pay 1000 a month so I can't afford it to fail, and if it does, I can't revert to 3.6.10!
Thanks so much for any help
The Heroku docs say your app continues to use the same Python version as when it was first deployed. In your case, the default would have been 3.6.10 when you first deployed your app, and this is no longer available. You can explicitly upgrade to 3.6.11 by creating a runtime.txt file.
It should be safe to upgrade between Python 3.6.X versions. If you want to be sure, then you could deploy a separate app on Python 3.6.11, or create a virtualenv locally and test on Python 3.6.11.
I can only assume Django defaults to 3.6.10
Django isn't controlling the Python version that Heroku is using. Each version of Django supports a range of Python versions. Check the release notes for your version.
i have some reasons witch i am stuck to use django on windows machine. i was wondering how to configure django on a windows sesrver 2012 r2 with iis 8.5. so i followed the tutorial here.
i did what the tutorial says and it is pretty much straight forward what i am gonna do for any kind of application i want to run with iis.
but i get the following error the fastcgi process exited unexpectedly.
here is what i have provided as executable for wfastcgi module:
E:\venvs\...\Scripts\python.exe|E:\venvs\...\Lib\site-packages\wfastcgi.py
i removed the wfastcgi.py part after | from handler mapping and error changed to script processor could not find the config for fastcgi configuration and i figured out the error must be related to the wfastcgi.py file. but i could not find the issue here. so i was wondering what can be the issue? and what are my options are here.
has any one been able to use django on a windows machine?? jsut in case my python version is python 3.6
I had the exact same problem as you but managed to solve this by using Python 3.4.2 version. Follow the exact steps as described in this tutorial Django with IIS and avoid using Python 3.5 or above because it seems that there are compatibility issues. The stack I used was IIS version 10, Windows 10, Python 3.4.2 and Django 1.11.2.
Upgrading wfastcgi to the latest version
pip install wfastcgi --upgrade
solved it for me: Python 3.6.6, wfastcgi 3.0.0
In my Case I was facing the same issue i.e. enter image description here
Mine is a Django App used for APIs that queries data from back-end platforms. This issue was only for specific filters that the API was using in queries while for other values in filters it worked great.
My Config file did not have a fastCgi tag and I added below mentioned part to top of system.webServer in config file. Yes off course it gave few errors here and there corresponding to activityTimeout and requestTimeout. Tried increasing up-to 900 and 601 respectively and then it worked for me. But could not understand cause of the issue as query that API was running for which i was facing this issue was not taking that long at all. I would like to understand that.
<fastCgi>
<application fullPath="D:\Python34\python.exe|D:\Python34\Scripts\wfastcgi.py"
arguments=""
maxInstances="4"
idleTimeout="300"
activityTimeout="900"
requestTimeout="601"
instanceMaxRequests="10000"
protocol="NamedPipe"
flushNamedPipe="false">
</application>
</fastCgi>
So I've been tasked with upgrading a Django server from 1.6.2 to the latest (~1.8), along with upgrading Python from 2.7.3 to 3.3. I suspect this is going to break quite a bit of code. (I even need to upgrade the Ubuntu installation from 12.04 to 14.04)
I would like to migrate my Django app from the server it's currently running on (Ubuntu 12.04) to a virtual machine, and use that environment as a sandbox to make changes.
Would anyone be so kind to provide guidance on django app migration? Please let me know if you'd like me to provide any specific details.
Thank you.
Edit: If anyone would like to vote down this question because they believe I haven't done enough research, I'm very happy to add missing information, if I know what you're looking for.
Django versions from 1.5 onwards has been designed so that the same code will work on both versions of Python as in the documentation thanks to them following the six compatibility layer.
You might face some issues with code that isn't strictly related to Django components like print statements and other such parts that might have been coded in. The official Python Porting Guide should held you with that.
Django 1.8 is a LTS (Long Term Release) so it's a good idea to upgrade to it. Migrating the database might be a bit of an issue considering it's from 2.7 to 3.4 but that's in all likelihood the place you'll find most issue with. The How to Migrate is a great resource.
If I recall correctly the directory structure is a bit different in 1.6 so you'll have to move some code and files manually. I suggest having the tutorial pages for both versions 1.6 and 1.8 open and comparing the directory structure.
Going through the first 2 pages of the tutorial should give you enough of an overview to migrate the database and the settings file. This should also help with migrations.
The 3rd and 4th pages should get you through migrating the views and urls files.
The only thing I'm not familiar with is the migration of the wsgi file which has configuration information, you should be able to find some basic information about that here.
Updating your Ubuntu however won't change or affect anything at all.
Also as has been said in the comments by jape and joel, it's a good idea to use virtualenv and git.
I would like to add another suggestion based on my own experience with pushing code to a Django server :
Download the code base to your local machine and work there and once you're done and the server is working well on your machine push it all to the server at once. That way you can isolate server machine specific issues from coding issues.
This is an old app, running since about two years on Heroku. Now suddenly, when I deploy (standard git push), it breaks the Python interpreter, both on regular and one-off dynos. Here's what it looks like:
$ heroku run python
Running `python` attached to terminal... up, run.8338
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Further pushes, heroku restart, scaling the dynos to zero and back up, that all doesn't fix it.
The only changes contained in this deployment which I could imagine being related to this problem are: gevent upgraded from 0.13.6 to 1.0.1 and the introduction of a runtime.txt (before there was none, resulting in 2.7.4, now there's one for 2.7.6).
I rolled all of this back to no effect, however. In fact, I went back about 30 commits (the deployment contained maybe five) and pushed that and the app is still broken.
Rolling back with heroku rollback is the only way I've found to take the app back into a usable state. But of course that doesn't help me going forward.
What might cause this? Can I somehow rebuild my whole app environment from scratch?
EDIT 1: I opened a shell in a one-off dyno and I can see the libpython2.7.so.1.0 file there:
/ $ ls -la /app/.heroku/python/lib/libpython2.7.so.1.0
-r-x------ 1 u49295 49295 5694572 2014-06-03 23:39 /app/.heroku/python/lib/libpython2.7.so.1.0
Of course I don't know if that's where it's supposed to be.
Somehow certain apps did not upgrade properly. A temporary fix to locate the correct python library:
heroku config:set LD_LIBRARY_PATH=/app/.heroku/python/lib
Kenneth Reitz from the Python team here.
So, we're rolling out security updates to the version of Python that we have installed on our base system. Customers shouldn't be affected by this in any way, because their apps use their own version of Python, and because we set local runtime-specific (such as LD_LIBRARY_PATH) in a .profile.d scripts, outside of user-set configuration.
However, we allow power users to override these environment variables with $ heroku config. That's basically what the application was doing — although, not knowingly. This was an accidental side-effect of a much, much older Heroku. In older days, we couldn't have any runtime-specific configuration without being a part of user configuration. This is why your application had an LD_LIBRARY_PATH config set, and this is what caused this bug.
Because of this, I've disabled the overridability of LD_LIBRARY_PATH for Python apps, and all should be well moving forward.
Thanks for being a part of the gradual rollout process, and thanks for helping us get to the bottom of this regression. I'm very sorry for the inconvenience.
Are you using the default Python buildpack? Heroku is in the process of updating the Stack image, and especially if you're not using a current buildpack, there may be incompatibilities.
To see if you're using a default buildpack, run
$ heroku config | grep BUILDPACK_URL
Please contact Heroku support if you think this might be the cause.
Installed Django 1.5 python2.7 mod_wsgi and python-sql on a red hat 4 web server with apache 2.
The "It worked" page keep flipping between the correct display and "internal server error" "500"
The flip occurs very frequently when pressing F5, but not only when quickly sending a request.
I have restarted Apache, erased wsgi that was configured for python 3.2 and reconfigured and installed for 2.7. I have also tried creating a new project, mysql database, and kicking the cat < not advisable.
On the python 3.2 installation I was having problems with the admin page registrations flipping between what I had applied, and being non-existent.
This error is occurring with debug = true, no apps installed, no database configuration yet, and what I assume is a complete baseline system aside from the wsgi file which seemed to work fine for the 3.2 installation.
If you are getting issues with the Python egg cache, see the mod_wsgi documentation at:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
The reason it flicks may be because you are running a multiprocess configuration and so requests can go to different processes. That it would be different though for different processes is a bit odd, but is often explained by import order dependencies in your code where whether it works depends on the order in which URLs are visited.
Quite often such ordering issues don't show up if using Django and developing with Django developer server, because the Django development server preloads code before requests are handled. I have commented on this specific Django issue in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Do note that code examples in that corresponded to an old Django version so may not be appropriate to use now.