Appengine deployment checking for success not working - google-app-engine

App engine (python 2.7, Mac OS X, latest version as of today) deployment seems to go fine (compilation completed) but deployment is stuck repeating "Will check again in 60 seconds" every 60 seconds until it finally fails, saying :
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/appcfg.py", line 2025, in Commit
raise Exception('Version not ready.')
Exception: Version not ready.
I've checked appengine status on code.google.com and nothing seems to go wrong.
Any idea if rollback is compulsory ? I had the same problem a couple of hours ago, but after a couple of tries it worked. This time it seems more serious, as i've been stuck in that state for a couple a hours now. Any advice ?

As mentioned in the comments, these types of issues are best served on the mailing list or issue tracker. However, for the particular issue you mentioned, a production issue was filed and resolved. You shouldn't be seeing this issue any longer.

Related

DatastoreFailureException: internal error

Just started getting this error - having made no code change.
GAE/J on Datastore Datanucleus JDO/JPA version: v1
my app on EU servers don't run.
US unaffected currently.
Suspect Google have broken something internally.
can anyone concur?
Yes, I started seeing a similar problem starting around 40 minutes ago. EU-based servers for my app as well. Refreshing works about 50% of the time.

Google App Engine Error: DNS lookup failed for URL: http://metadata.google.internal

I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.

GAE downloading log with LogQuery

My application generates many, many log messages. I would like to download only messages in a specific time interval. I looked around and LogQuery seems to be a good choice.
It seems like LogQuery, as specified here:
https://developers.google.com/appengine/docs/java/javadoc/com/google/appengine/api/log/LogQuery.Builder
, let one specify a start and end time in milliseconds.
However, there is no such method withStartTimeMillis or withEndTimeMillis in the GAE library that I downloaded from the web. I'm using GAE SDK 1.7.1. There are only withStartTimeUSec and withEndTimeUsec which deal in microsecond.
What's amiss here?
LogQuery.Builder has both methods: withStartTimeMillis(long startTimeMillis) and withStartTimeUsec(long startTimeUsec).
Also, the current version is 1.8.1, so you should upgrade to that before starting to resolve errors.

App Engine upload issues.

I'm no longer able to upload code to my app engine app. The following are the symptoms that I'm experiencing:
Code compiles and files are uploaded. Update fails during "Verifying availability" Here's the specific stuff from the console:
Deploying new version.
Verifying availability:
Will check again in 1 seconds.
Will check again in 2 seconds.
Will check again in 4 seconds.
Will check again in 8 seconds.
Will check again in 16 seconds.
Will check again in 32 seconds.
Will check again in 60 seconds.
.
.
.
Will check again in 60 seconds.
Will check again in 60 seconds.
Will check again in 60 seconds.
on backend null.
java.lang.RuntimeException: Version not ready.
When I look in the Admin Console it indicates that the new version uploaded, however, the old code is still running. I tried using a different machine to upload a Hello World example to isolate my main development machine and project. I get the same result with the other machine/app. I also tried to upload the app from the command line but got the same result. I ran appcfg.sh rollback (I'm on a Mac) and it completes without error but still the problem persists.
I don't recall a specific change to my app engine configuration immediately before the problem began, but I had changed the version to 0.1 within a couple of hours of my problems starting. The app engine rejected the version number due to the period in the version number. It took a long time to figure this out because the feedback was cryptic. I mention this because a) the feedback was cryptic and b) the error specifically mentions "Version not ready".
Can anyone help me figure out what I did and how to undo it? If it helps, my app ID is milkmooseexperimental
Thank you.
It's a Server Side issue. I'm experiencing the same problem as well, and have been unable to deploy for the last 12 hours. I'm not sure whether this has anything to do with the scheduled outage window.

Error 500 on Google App Engine out of nothing

I got Error 500 on Google App Engine out nothing.
http://oladic.appspot.com/ - this got error.
The same code runs flawlessly at:
http://blogthere.appspot.com/
and
http://912.latest.oladic.appspot.com/
How could this be?
This issue has been resolved. The post on the downtime-notify list is here:
http://groups.google.com/group/google-appengine-downtime-notify/browse_thread/thread/7fb8a39149de3b55
The update on the system status page is here:
http://code.google.com/status/appengine/detail/datastore/2010/02/02#ae-trust-detail-datastore-get-latency
You can see the System Status and check if the error was when the system had problems
I had this problem for 2 days, turns out it because I'm not listed on Google's "Trusted Developers List?" My only issue now is why Google doesn't return a meaningful error message..
Here's their own thread on the matter. See for yourself.
http://code.google.com/appengine/forum/go-forum.html?place=topic/google-appengine-go/zdMysT6yO30
App Engine appears to be borked this morning, lots of people are having this problem on the mailing list as well.
My site has just, somewhat unexpectedly, come back online, with no work done by myself.
I assume it was a temporary problem with the App Engine, and, with any luck, your site should come back up soon.
In my case, the problem appeared when I decided to deploy the application. After inquire for a while, I figured out that the problem was being caused due the imports of simplejson (in MacOS) or json (in Windows).
The solution to this, is to import the libraries from django. In my case I did:
from django.utils import simplejson
I hope this solution will work for you.
I had a similar problem, and like Harph above i eventually realized that the use of a JSON module via the following import:
import json
was the cause of the error (at the Engine side) -something that was not problematic at the development server
I corrected this to
from django.utils import simplejson
And this has solved the problem.
thanks Harph for the tip.
Note: Another very important thing that I'd overlooked, that might actually make it harder for other devs working with the GAE for the first time, is not using the Error Logs in the Admin Console (at the datastore admin interface). This is i believe the surest way to quickly pin down the cause of problems at the GAE side (especially ones you don't see at the development server).

Resources