search

straight55b / app-engine-patch

Automatically exported from code.google.com/p/app-engine-patch
0 stars 0 forks source link

manage.py update fails to update indexes #117

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. run 
manage.py update 
in your project dir

What is the expected output? What do you see instead?
Application update runs fine, however at the stage of uploading indexes
process fails to redirect. However 
appcfg.py update_indexes .
works fine

What version of the product are you using? On what operating system?
1.1beta

Please provide any additional information below.
>manage.py update
Running on app-engine-patch 1.1beta1
Scanning files on local disk.
Scanned 500 files.
Scanned 1000 files.
Scanned 1500 files.
Initiating update.
Cloning 114 static files.
Cloned 100 files.
Cloning 568 application files.
Cloned 100 files.
Cloned 200 files.
Cloned 300 files.
Cloned 400 files.
Cloned 500 files.
Deploying new version.
Checking if new version is ready to serve.
Will check again in 1 seconds.
Checking if new version is ready to serve.
Closing update: new version is ready to start serving.
Uploading index definitions.
Traceback (most recent call last):
  File "manage.py", line 18, in <module>
    execute_manager(settings)
  File "/project_dir/__init__.py", line 370, in execute_manager

  File "/project_dir/__init__.py", line 315, in execute

  File
"/project_dir/common/zip-packages/django-1.0.2.zip/django/core/management/comman
ds/update.py",
line 64, in run_from_argv
  File
"/project_dir/common/zip-packages/django-1.0.2.zip/django/core/management/comman
ds/update.py",
line 47, in run_appcfg
  File "/project_dir/__init__.py", line 178, in call_command

  File
"/project_dir/common/zip-packages/django-1.0.2.zip/django/core/management/base.p
y",
line 227, in execute
  File
"/project_dir/common/zip-packages/django-1.0.2.zip/django/core/management/base.p
y",
line 356, in handle
  File
"/project_dir/common/zip-packages/django-1.0.2.zip/django/core/management/comman
ds/syncdb.py",
line 66, in handle_noargs
  File "/ae_lib_dir/google/appengine/ext/db/__init__.py", line 1365, in count
    return self._get_query().Count(limit=limit)
  File "/ae_lib_dir/google/appengine/api/datastore.py", line 962, in Count
    self._ToPb(limit=limit), resp)
  File "/ae_lib_dir/google/appengine/api/apiproxy_stub_map.py", line 68, in
MakeSyncCall
    apiproxy.MakeSyncCall(service, call, request, response)
  File "/ae_lib_dir/google/appengine/api/apiproxy_stub_map.py", line 240,
in MakeSyncCall
    stub.MakeSyncCall(service, call, request, response)
  File "/ae_lib_dir/google/appengine/ext/remote_api/remote_api_stub.py",
line 172, in MakeSyncCall
    response)
  File "/ae_lib_dir/google/appengine/ext/remote_api/remote_api_stub.py",
line 135, in MakeSyncCall
    request_pb.Encode()))
  File "/ae_lib_dir/google/appengine/tools/appengine_rpc.py", line 303, in Send
    f = self.opener.open(req)
  File "/usr/lib/python2.5/urllib2.py", line 387, in open
    response = meth(req, response)
  File "/usr/lib/python2.5/urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.5/urllib2.py", line 425, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 302: Moved Temporarily

Original issue reported on code.google.com by A.A.Vasi...@gmail.com on 27 Mar 2009 at 1:51

GoogleCodeExporter commented 9 years ago 
The index runs fine. It's just the remoteapi handler which is missing. Did you 
update
your app.yaml as described in the release notes?

Original comment by wkornew...@gmail.com on 29 Mar 2009 at 10:46

GoogleCodeExporter commented 9 years ago 
my app.yaml has now:

handlers:
- url: /remote-23sdfklsdf5LjfDp-url
  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
  login: admin

settings.py has:

DATABASE_OPTIONS = {
    'remote_url': '/remote-23sdfklsdf5LjfDp-url',
}

I changed url as suggested.

Original comment by A.A.Vasi...@gmail.com on 30 Mar 2009 at 3:24

GoogleCodeExporter commented 9 years ago 
Good, so is it fixed? :)

Also, you sould change your URL, again, now that you've posted it publicly. ;)

Original comment by wkornew...@gmail.com on 30 Mar 2009 at 7:06

GoogleCodeExporter commented 9 years ago 
No its not. The same exception. 

Please tell nobody, but I posted a fake. ;)

Original comment by A.A.Vasi...@gmail.com on 30 Mar 2009 at 3:58

GoogleCodeExporter commented 9 years ago 
That's really strange. Could it be that some other app.yaml handler is matching
before remoteapi? Or do you possibly have a / at the end of your real remoteapi 
URLs?
I can't reproduce this problem over here.

Original comment by wkornew...@gmail.com on 31 Mar 2009 at 10:44

GoogleCodeExporter commented 9 years ago 
Still not resolved?

Did you add the DATABASE_OPTIONS or did you modify the existing one at the 
bottom of
settings.py? Maybe your options simply get overwritten?

Original comment by wkornew...@gmail.com on 2 Apr 2009 at 9:32

GoogleCodeExporter commented 9 years ago 
Now in root settings.py (and only there) I have just:

DATABASE_OPTIONS = {
    'remote_url': '/remote_api',
}

and in app.yaml
handlers:
- url: /remote_api
  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
  login: admin

But this default url also not working. Now I got HTTP Error 500 (log attached)
You see, /remote_api is the first handler in my app.yaml and it is still not
recognized when I try to upload indexes. My app now is down that is why I dot 
500,
not 302 (page not found, I guess).

Could it be something like cr/lf not stripped properly? I am coding in linux 
and have
'lf's only.

Original comment by A.A.Vasi...@gmail.com on 2 Apr 2009 at 11:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Wait, /remote_api is triggered: In the console I see:
Errors help URI     Count   % Errors last 10 hrs
/remote_api
    12  100% 

i.e. 12 tries resulted in 100% errors

Original comment by A.A.Vasi...@gmail.com on 2 Apr 2009 at 4:46

GoogleCodeExporter commented 9 years ago 
Now my site is up (indexes are built), but I still have
urllib2.HTTPError: HTTP Error 500: Internal Server Error

Original comment by A.A.Vasi...@gmail.com on 2 Apr 2009 at 4:50

GoogleCodeExporter commented 9 years ago 
Does anything appear in the admin console's logs?

Original comment by wkornew...@gmail.com on 2 Apr 2009 at 5:52

GoogleCodeExporter commented 9 years ago 
Sometimes I seems retarded even to myself.
No, the is no log entries for '/remote_api' requests,
however dashboard count increases after each
manage.py update
attempt:
/remote_api
       16      100%
BTW, incoming request in dashboard for /remote_api are without
trailing slash! Others (/ , /news/, etc) have trailing slash and are
successful.

Original comment by A.A.Vasi...@gmail.com on 3 Apr 2009 at 2:20

GoogleCodeExporter commented 9 years ago 
This one is really tough. :)

Did "manage.py update" ask for a password after the index definitions got 
uploaded?

Could you please try to remove the appcfg configuration file, so all cookies get
flushed and then try again?

Original comment by wkornew...@gmail.com on 3 Apr 2009 at 5:19

GoogleCodeExporter commented 9 years ago 
manage.py throws an exception when uploading index definition and then exits. 
Full
console log attached.

Original comment by A.A.Vasi...@gmail.com on 4 Apr 2009 at 1:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Please take a closer look at the log file. You will notice that syncdb is 
executed
which happens after the index definitions get uploaded successfully. I've 
updated our
repo version, so it prints out "Running syncdb.".

Did you try what I suggested in comment 12?

I just can't imagine that there is no log entry for /remoteapi. Please take a 
close
look at the tracebacks. Is there any traceback containing the word "remote"?

Original comment by wkornew...@gmail.com on 4 Apr 2009 at 6:43

GoogleCodeExporter commented 9 years ago 
Yes, you are right. After updating with your changes, there is 'Running 
syncdb.' line
in the log. By the way, it goes to stdout, while majority of log output goes to
stderr (I attached err.log too). You can see that at the command line I delete 
AE
cookies.

Finally I found server-side logs: I set 'Minimum Severity:' to 'Requests only' 
for
this. There are 4 identical (different in timestamp) log entries. Here is one:
############################################
      04-04 01:50AM 08.496 /remote_api 500 4ms 0ms-cpu 0kb Google-remote_api/1.0
Linux/2.6.27.19-170.2.35.fc10.i686.PAE Python/2.5.2.final.0,gzip(gfe)
      See details

      84.237.97.150 - - [04/Apr/2009:01:50:08 -0700] "POST /remote_api HTTP/1.1" 500
0 - "Google-remote_api/1.0 Linux/2.6.27.19-170.2.35.fc10.i686.PAE
Python/2.5.2.final.0,gzip(gfe)"
############################################

As for 'See details' link, I see empty page there.

Original comment by A.A.Vasi...@gmail.com on 4 Apr 2009 at 9:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Do you see anything for remoteapi if you set minimum severity to DEBUG?

Original comment by wkornew...@gmail.com on 4 Apr 2009 at 10:02

GoogleCodeExporter commented 9 years ago 
Nothing for remote_api. Only 'normal' pages requests.

Original comment by A.A.Vasi...@gmail.com on 4 Apr 2009 at 12:30

GoogleCodeExporter commented 9 years ago 
OK, could you please take the sample project (unmodified) and do manage.py 
update to
one of your appids?

If this doesn't work there must be a bug in app engine.

Original comment by wkornew...@gmail.com on 4 Apr 2009 at 1:15

GoogleCodeExporter commented 9 years ago 
Instead of throwing exception, for aep-sample it prints right after 'Running 
syncdb.':

Username:a.a.vasiljev
Password:

In the case of sample project these are two last lines in the log.
Magic!

Original comment by A.A.Vasi...@gmail.com on 4 Apr 2009 at 4:39

GoogleCodeExporter commented 9 years ago 
I'll try to look at the diffs tomorrow.

Original comment by A.A.Vasi...@gmail.com on 4 Apr 2009 at 5:03

GoogleCodeExporter commented 9 years ago 
Does it work correctly after you enter your username and password?

BTW, the syncdb login is required because you're accessing the remoteapi handler
(syncdb is being executed remotely on the production datastore).

Original comment by wkornew...@gmail.com on 4 Apr 2009 at 5:27

GoogleCodeExporter commented 9 years ago 
Yes, it works correctly. I.e. there are no errors for sample project.
I don't quite understand what syncdb could do with an empty DB ;)

I also successfully uploaded MY OWN project to another appID. It seems that the
reason of exception is in the data at the server. Logs are not accessible. I 
think
it's time to file a new AE bug.

Original comment by A.A.Vasi...@gmail.com on 5 Apr 2009 at 11:50

GoogleCodeExporter commented 9 years ago 
Actually, syncdb is (unlike the name might imply) a command for initializing 
the DB
(e.g., creating an admin user when no users exist, etc.).

Well, I'll close this one since it seems to not be aep-related.

Original comment by wkornew...@gmail.com on 5 Apr 2009 at 11:55

GoogleCodeExporter commented 9 years ago 
I know the issue has been closed, but I was wrangling with the same issue, and 
came to a resolution I thought 
I would pass on, in case it was relevant to this topic.  (And, because there is 
not a lot of commentary on the 
web for the error at this point).

I was consistently getting the aforementioned 302/500 errors for anything I 
tried to do remotely, be it 
'manage.py update' or 'manage.py shell'. Whenever the RPC was actually 
triggered, I would get the errors. 
What I did notice is that the application I was deploying to was restricted to 
users from a given domain.  When 
I changed the deployment to a fully public application (burning another slot 
since you can't AFAIK change this 
for a preexisting app), everything worked just fine.

Original comment by quiet.d...@gmail.com on 9 May 2009 at 10:58

GoogleCodeExporter commented 9 years ago 
It's time to fix the issue, Waldemar! ;)

Attached patch made against module django.db.backends.appengine.base of
appenginepatch-sample's django-1.1.zip

The story is: my application is bound with aikido.nsk.su Google Apps domain, so 
to get
manage.py shell --remote
and
manage.py update (syncdb part) 
working, I need to 

1.
configure my settings.py

DATABASE_OPTIONS = {
    'remote_host': 'www.aikido.nsk.su',
}

2. 
provide my Google Apps domain credentials doing syncdb or shell --remote (It 
would
ask for a login and password for the first time)

BUT you need this patch to get it working

Original comment by A.A.Vasi...@gmail.com on 11 May 2009 at 4:03

Attachments:

GoogleCodeExporter commented 9 years ago 
Oh, that was a stupid bug! I'll commit the fix, soon. Thanks a lot 
(спасибо), Alex!!! :)

Original comment by wkornew...@gmail.com on 12 May 2009 at 5:57