D:\kubox\python\GAE>appcfg.py rollback D:\kubox\python\GAE\myapp1
Traceback (most recent call last):
File "D:\kubox\python\GAE\appcfg.py", line 77, in <module>
DIR_PATH = get_dir_path(os.path.join('lib', 'ipaddr'))
File "D:\kubox\python\GAE\appcfg.py", line 67, in get_dir_path
'file and %s.' % sibling)
ValueError: Could not determine directory that contains both, this file and lib\
ipaddr.
After a failure deployment, I can't perform the appcfg.py, did I make a wrong syntax?
where did I do wrong?
WIN 7, cmd prompt
Try running appcfg.py from where your GAE SDK is installed.
Usually rollback should suffice, but after a failure in deployment, sometimes the upload doesn't work by default.
As a work around, you can change the app version (app.yaml), and then try deployment, It should go fine.
Next you can log in to your applications dashboard and in versions tab, you can switch the latest version as default one. Your new version should be up and running now.
As a last step you can stop any instances of old version of your app.
Hope this helps
Related
We are not able to deploy our app anymore to App Engine Standard.
Steps to reproduce: we simply deploy our project with IntelliJ IDEA - we get the following error:
Beginning deployment of service [default]...
#============================================================#
#= Uploading 0 files to Google Cloud Storage =#
#============================================================#
File upload done.
Updating service [default]...
.................................................................................failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build 15c72c99-c2cc-4e4d-b910-0eee13a9cb5a status: FAILURE.
Error ID: 6AA2815A.
Error type: BuildError.
Error message: 21 Feb 2020 04:36:00 INFO Running as user 0, group 0
21 Feb 2020 04:36:00 INFO Arguments: ['--name=eu.gcr.io/XXXXXXX/app-engine-tmp/app/ttl-2h:af4f2b82-4138-4c9a-905f-6f9cf038e4cd', '--src=/workspace', '--base=eu.gcr.io/gae-runtimes/java8:java8_20191215_8_0_RC00']
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/bin/appender.par/__main__.py", line 90, in <module>
File "/bin/appender.par/__main__.py", line 76, in main
File "/bin/appender.par/containerregistry/client/v2_2/append_.py", line 74, in __init__
File "/bin/appender.par/containerregistry/client/v2_2/docker_image_.py", line 110, in uncompressed_blob
File "/usr/lib/python2.7/gzip.py", line 260, in read
self._read(readsize)
File "/usr/lib/python2.7/gzip.py", line 319, in _read
self._add_read_data( uncompress )
File "/usr/lib/python2.7/gzip.py", line 337, in _add_read_data
self.extrabuf = self.extrabuf[offset:] + data
MemoryError.
Failed to deploy '[2020-02-21 06:33:21] XXXX:war exploded. Project: XXXXXX. Version: vvvv': Deployment failed with exit code: 1
Please make sure that you are using the latest version of the Google Cloud SDK.
Run ''gcloud components update'' to update the SDK. (See: https://cloud.google.com/sdk/gcloud/reference/components/update.)
The Cloud SDK is managed by IDEA .. it seems to be the latest version (in Settings - Cloud SDK).
We have another smaller test project in IDEA which we can deploy without issues.
And we have another larger project in Eclipse which fails with a similar error - MemoryError.
I guess there must be some Memory issue in Google Cloud since the smaller project works fine, but the 2 larger projects do not work!!
This happens since yesterday .. we searched but could not find any similar issues .. so I guess this must be something new?
UPDATE:
It seems to work now .. I guess it was a temporary glitch in the Google deployment process.
For issues like this, it would be better to open a ticket to the Google Cloud Platform support team. They will be able to troubleshoot it better with access to the specifics of your environment and the logs.
I've been running app engine local development server from the command prompt for 3 years without any issues (windows 7, 64bit). I just updated to v1.9.36 (download 960cfe2157c6e984802db4b0224cfe8273d727dc from this page), and now when I run
dev_appserver.py [anything]
I get:
Traceback (most recent call last): File "C:\Program
Files\Google\Cloud
SDK\google-cloud-sdk\platform/google_appengine\dev_appserver.py", line
82, in
_run_file(file, globals()) File "C:\Program Files\Google\Cloud
SDK\google-cloud-sdk\platform/google_appengine\dev_appserver.py", line
78, in _run_file
execfile(_PATHS.script_file(script_name), globals_) File "C:\Program Files
(x86)\Google\google_appengine\google\appengine\tools\devappserver2\devappserver2.py",
line 37, in
from google.appengine.tools.devappserver2 import dispatcher File "C:\Program Files
(x86)\Google\google_appengine\google\appengine\tools\devappserver2\dispatcher.py",
line 29, in
from google.appengine.tools.devappserver2 import module File "C:\Program Files
(x86)\Google\google_appengine\google\appengine\tools\devappserver2\module.py",
line 55, in
from google.appengine.tools.devappserver2 import http_runtime File "C:\Program Files
(x86)\Google\google_appengine\google\appengine\tools\devappserver2\http_runtime.py",
line 53, in
import portpicker ImportError: No module named portpicker
The strange thing is that if I use the SDK GUI, and hit the 'Run' button, it launches just fine, no errors. So my guess is that when running from the command line, it's using the version of 'dev_appserver.py' in the Cloud SDK folder, whereas the GUI is running the version in C:\Program Files (x86)\Google\google_appengine\. But my environment variables are:
GAE_SDK_ROOT: C:\Program Files (x86)\Google\google_appengine
PATH: lots of other things, plus C:\Program Files (x86)\Google\google_appengine\
And I dont see any reference to Cloud SDK, so I cant figure why the version in the folder would be run.
There are versions of dev_appserver.py in both C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine and C:\Program Files (x86)\Google\google_appengine
Seems that in combining GAE SDK with Google Cloud, Google has made this more complicated than it used to be..
[UPDATE]
If I run echo %PATH% then among many other things, I see
C:\Program Files\Google\Cloud SDK\google-cloud-sdk..
before
C:\Program Files (x86)\Google\google_appengine\
Which explains why it's running that version. The question now is: why is the former in my PATH if I havent set it in my user PATH variable? Where else is the Windows PATH manipulated? Presumable the Google Cloud SDK installer did this - how do I undo it?
Executing dev_appserver.py [anything] will launch the first dev_appserver.py executable encountered in your executable PATH environment, which appears to be not the one you expect :)
You have 2 options:
update your PATH as needed
execute the desired dev_appserver.py by specifying its full path:
C:\Program Files (x86)\Google\google_appengine\dev_appserver.py [anything]
This answer is somehow related: appcfg.py not working in command line
New answer
I turns out that the Cloud SDK folder was in my system path, which is checked before the user path, so the version of dev_appserver.py in Cloud SDK was being executed, rather than the more up to date version in the app engine folder.
To fix this I simply removed the Cloud SDK from my system path, using the handy app detailed here
Original answer
I worked out that if I rename the Cloud SDK folder in C:\Program Files\Google this fixes it. But that's a hacky fix, and presumably makes the Cloud SDK functionality unavailable (I dont think I currently need it).
So I'd still like a proper answer to this question. It seems that I need a way to control which version of dev_appserver.py gets run, and short of setting my environment variables (which I've already done) I dont know what else to try.
As an alternative to the other answers, if you do not have the old standalone Google App Engine installed and only uses the Google SDK, you can also install portpicker with the following command line (assuming you have pip installed):
pip install portpicker
I have followed all the steps on https://cloud.google.com/appengine/docs/go/#creating_a_simple_http_handler on how to get started with Go, but I am stuck on an issue while trying to run the helloworld app.
I get the following error:
C:\Users\kirill\Desktop\go_appengine>goapp serve myapp
Traceback (most recent call last):
File "C:\Users\kirill\Desktop\go_appengine\\dev_appserver.py", line 83, in <module>
_run_file(__file__, globals())
File "C:\Users\kirill\Desktop\go_appengine\\dev_appserver.py", line 79, in _run_file
execfile(_PATHS.script_file(script_name), globals_)
NameError: name 'execfile' is not defined
error while running dev_appserver.py: exit status 1
Go AppEngine SDK requires Python 2.7 (Python 3.x cannot be used). It looks to me your SDK is using Python 3.X or you don't have Python at all (in your PATH).
First make sure Python 2.7 is added to your PATH so that will be used by goapp. You can get it here: Python 2.7.11. For the Go AppEngine SDK a small, portable Python is also enough, you can get it from here: Single-File Stand-alone Python 2.7.9 for Windows. Download pyexe-2.7.9.10.zip and extract it. It's just a 10 MB single file, rename it to python.exe and add it to your PATH.
Also going further, it looks to me you are starting your Hello world app from the wrong folder: you are standing in the SDK's folder, and you want to start it specifying that your app is in the myapp subfolder inside your SDK, which is unlikely.
Navigate to the folder where you app is (app.yaml must be there). In that folder execute the command
goapp serve
This will start the app being in the current folder. For this to work, the goapp command (goapp.bat on windows) must be added to your PATH.
If you can't or don't want to add your go_appengine folder to your PATH, still navigate to the folder containing the app you want to start, but provide the path for goapp, e.g.
C:\Users\kirill\Desktop\go_appengine\goapp serve
I've just stumbled upon similar issue myself, In Python 3
Instead of
execfile("./filename")
Use
exec(open("./filename").read())
I built a new project using buildout for Pyramid and GAE under Ubuntu 12.04 (using pyramid_appenegine pcreate template). I started a new VM to ensure no messing with distribute and setuptools in site-packages.
First of all, it results in that setuptools not found error, apparently solved with the patch provided by Tom Willis.
Then, buildout finishes building ok, but starting the develop site results in that error:
funky#funkydesktop:~/dev/gae1$ bin/devappserver parts/gae1
Traceback (most recent call last):
File "bin/devappserver", line 25, in <module>
sys.exit(dev_appserver._run_file('/home/funky/dev/gae1/parts/google_appengine/dev_appserver.py', locals()))
AttributeError: 'module' object has no attribute '_run_file'
Any hints to solve that one, or the whole process of building and starting the application?
I finally solved the problem by changing ae-sdk-version to 1.8.0.
Open buildout.cfg and change the line
ae-sdk-version=1.7.5
to:
ae-sdk-version=1.8.0
Or either you could see what happens with pyramid_appengine version (I got 0.8.1 instead of 0.8.2-a2 which is the current one in pypi.python.org). This is the package that holds the template.
I am trying to run pyramid application on google's app engine using buildout. I followed this link gae_buildout and got struck while running the buildout. Its shows "setuptools not found error" despite of seetuptools being installed in the virtual environment. I tried few work arounds and nothing turned fruitful, any thoughts on this ?
Find the error trace below. I am using pyramid 1.4 version.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1942, in main
getattr(buildout, command)(args)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 622, in install
installed_files = self[part]._call(recipe.install)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1366, in _call
return f()
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 377, in install
self.copy_packages(ws, temp_dir)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 284, in copy_packages
self.write_pkg_resources(ws, lib)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 267, in write_pkg_resources
assert len(setuptools_eggs) == 1, "setuptools not found"
AssertionError: setuptools not found
Got the same (Ubuntu 12.04) and finally solved the problem by changing ae-sdk-version to 1.8.0 from buildout.cfg
Open buildout.cfg and change the line:
ae-sdk-version=1.7.5
to:
ae-sdk-version=1.8.0
...or the latest one from here. Now seems to be 1.8.5, but 1.8.0 worked for me.
The problem in fact comes because PyPI is not serving last version of pyramid_appengine. It's serving 0.8.1 and should be (latest) 0.8.2-a2. You can download and install in your virtualenv the latest version in a tarball from here: https://pypi.python.org/pypi/pyramid_appengine/
So here's another solution.
It seems that rod.recipe.appengine doesn't work with the setuptools versions of the system, and it doesn't download the last version in that buildout. So the solution is to force to download a newer version of setuptools that rod.recipe.appengine likes.
Edit the versions.cfg file (should appear just the [versions] tag) and add the following line:
[versions]
setuptools = 1.1.7
(other older versions work as well, I tested successfully with 0.9.8)
And now seems to work easier without needing the mentioned patches (thanks Tom) that are harder to update.
This happened to me as well.
I started looking at the code and noticed it was explicitly looking for an egg install of setuptools, and none of the places I had installations of it were eggs for some reason.
I decided I'd go delete them from my site-packages and re-run the tools to download them, and after only killing the copy in my virtual env, and re-running the bootstrap and buildout, it got the egg and everything started working fine.