Closed Bug 669391 Opened 15 years ago Closed 15 years ago

Need boxes for Sheriff app

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: laura, Assigned: fox2mike)

References

Details

(Whiteboard: [2011q3])

The new version of the Sheriff app: https://bugzilla.mozilla.org/show_bug.cgi?id=571886 needs to ship this quarter as a webdev goal. It's early days yet but I just wanted to get the bug filed so you can plan Q3 appropriately. App will be playdoh + MySQL and live behind LDAP for auth. More details to follow.
See Also: → 571886
Corey, this goes on the seamicro?
Assignee: server-ops → shyam
For the Sheriff app what we need is, basically, basic Playdoh with a lot of stuff commented out (such as celeryd): * MySQL * smtp (not a package but a host name to use) * java (for compressing static files with YUICompressor) Compiled python packages * MySQL-python==1.2.3c1 * Jinja2==2.5.5 * hmac==20101005 * hashlib==20081119 * py-bcrypt==0.2 (All of these are installable from `pip install -r requirements/compiled.txt` What is yet to be decided is LDAP integration. Either... A) the python-ldap libraries so I can manually connect to the LDAP server within my login function and decide on permissions based on LDAP groups. or... B) the LDAP Apache thing so that headers are forwarded into the app that I can pick up. Although this is convenient I'm assuming this disables all anonymous traffic for reading which might be a bit disadvantage to its users.
This is pretty much code complete. Could we get an ETA on the hardware?
fox2mike, sheriff1.dev.seamicro.phx1.mozilla.com sheriff1.stage.seamicro.phx1.mozilla.com
What's the repo for this? I assumed it was https://github.com/peterbe/sheriffs is that correct?
Stuff is setup, LDAP based auth won't work till netops flexes their muscles on the firewall.
Also, when I removed auth to see what the site is like, I hit an ISE : [Fri Jul 22 01:21:13 2011] [info] [client 10.8.33.248] mod_wsgi (pid=26852, process='', application='sheriff-dev.allizom.org|'): Loading WSGI script '/data/www/python/sheriff.mozilla.org/sheriffs/wsgi/playdoh.wsgi'. [Fri Jul 22 01:21:16 2011] [error] [client 10.8.33.248] mod_wsgi (pid=26852): Exception occurred processing WSGI script '/data/www/python/sheriff.mozilla.org/sheriffs/wsgi/playdoh.wsgi'. [Fri Jul 22 01:21:16 2011] [error] [client 10.8.33.248] Traceback (most recent call last): [Fri Jul 22 01:21:16 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/vendor/src/django/django/core/handlers/wsgi.py", line 250, in __call__ [Fri Jul 22 01:21:16 2011] [error] [client 10.8.33.248] self.load_middleware() [Fri Jul 22 01:21:16 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/vendor/src/django/django/core/handlers/base.py", line 45, in load_middleware [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] mod = import_module(mw_module) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/vendor/src/django/django/utils/importlib.py", line 35, in import_module [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] __import__(name) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/apps/commons/middleware.py", line 16, in <module> [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] from .helpers import urlparams [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/apps/commons/helpers.py", line 10, in <module> [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] from jingo import register [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/vendor/src/jingo/jingo/__init__.py", line 140, in <module> [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] env = get_env() [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/data/www/python/sheriff.mozilla.org/sheriffs/vendor/src/jingo/jingo/__init__.py", line 58, in get_env [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] e = Environment(**opts) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/usr/lib/python2.6/site-packages/jinja2/environment.py", line 269, in __init__ [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] self.extensions = load_extensions(self, extensions) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/usr/lib/python2.6/site-packages/jinja2/environment.py", line 73, in load_extensions [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] extension = import_string(extension) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] File "/usr/lib/python2.6/site-packages/jinja2/utils.py", line 195, in import_string [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] return getattr(__import__(module, None, None, [obj]), obj) [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] AttributeError: 'module' object has no attribute 'with_'
(In reply to comment #5) > What's the repo for this? I assumed it was > https://github.com/peterbe/sheriffs is that correct? Not really. It's tucked away in a git branch called 'develop' I'll make the first release so that all you need to do is git clone.
(In reply to comment #7) [snip] > [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] return > getattr(__import__(module, None, None, [obj]), obj) > [Fri Jul 22 01:21:17 2011] [error] [client 10.8.33.248] AttributeError: > 'module' object has no attribute 'with_' Did you run all the `pip install -r requirements/compiled.txt`? Anyway, doing that without the right git branch won't also make you install python-ldap. In fact, recently there's been problems with python-ldap. At least on OSX. See if you can first install Jinja2 and python-ldap using the OS packages.
For the record, I have now moved the repo, made a release and changed the default branch to be "master". https://github.com/mozilla/sheriffs If you git clone this one you should get the very latest and greatest (tagged as 2011-07-22)
Shyam, I now realise I forgot to make a sample local settings file. Anyway, what you need to do is create a file called: ./settings/local.py and put the following into it:: from base import * DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'sheriffs', 'USER': xxxx, 'PASSWORD': xxxxx, 'HOST': '', 'PORT': '', 'OPTIONS': { 'init_command': 'SET storage_engine=InnoDB', 'charset' : 'utf8', 'use_unicode' : True, }, 'TEST_CHARSET': 'utf8', 'TEST_COLLATION': 'utf8_general_ci', }, } AUTH_LDAP_SERVER_URI = 'ldap://pm-ns.mozilla.org' AUTH_LDAP_BIND_DN = xxxxx # same as Elmo AUTH_LDAP_BIND_PASSWORD = xxxxx
backpedelling here.. this can and should go on the generic cluster. The bug subject "need boxes" is misleading, we don't need dedicated seamicros for this. It will get better support on generic. I'll see about moving this soon.
(In reply to comment #12) > backpedelling here.. this can and should go on the generic cluster. The > bug subject "need boxes" is misleading, we don't need dedicated seamicros > for this. > > It will get better support on generic. > > I'll see about moving this soon. ugh, nevermind this.. I forgot about the whole java side to this. Let's go with the individual nodes. sorry, losing my mind.
(In reply to comment #9) > Did you run all the `pip install -r requirements/compiled.txt`? hrmm we deploy services through puppet.. running commands like this on an individual node doesn't scale. That said, I believe there is a new pip provider for puppet - will see what we can do.
(In reply to comment #13) > (In reply to comment #12) > > backpedelling here.. this can and should go on the generic cluster. The > > bug subject "need boxes" is misleading, we don't need dedicated seamicros > > for this. > > > > It will get better support on generic. > > > > I'll see about moving this soon. > > ugh, nevermind this.. I forgot about the whole java side to this. Let's go > with the individual nodes. > > sorry, losing my mind. I'm surprised we don't use YUICompressor on something else. peterbe, can we use the django_compressor instead to get rid of the Java dependency?
(In reply to comment #15) > I'm surprised we don't use YUICompressor on something else. > > peterbe, can we use the django_compressor instead to get rid of the Java > dependency? This would be ideal. If we can work this into the generic cluster it will be easier for us to support.
Moving to django_compressor won't be uber easy since we're using the "Playdoh way" which is to use the compress command which relies on java. If you'd like I think we can somewhat easily change this to rely on other technologies such as Node or cssmin (which is python). Would you like me to attempt that?
Sorry, my answer wasn't clear. Moving to django_compressor won't be harder just because we rely on java. It's a major change to the templates. I'd be much happier to just change the binary used to do the compression. What do you prefer, Node or that I find a python solution?
Laura/Peter, I'm pretty sure we use YUICompressor with SUMO and other websites..it's why mradm02 has java installed. I think we can stick with that? Sorry, I haven't had any time to debug why sheriffs isn't up yet, will try to do that today or tomm.
Oh if this is only needed on the admin node then we can do that.. (YUICompressor) Sorry, details are lacking here, I assumed java was needed on the webheads.
# ./manage.py syncdb Traceback (most recent call last): File "./manage.py", line 33, in <module> from django.core.management import execute_manager ImportError: No module named django.core.management Are you missing vendor libs, or are we missing some instructions that would make the above command work?
(In reply to Corey Shields [:cshields] from comment #21) > # ./manage.py syncdb > Traceback (most recent call last): > File "./manage.py", line 33, in <module> > from django.core.management import execute_manager > ImportError: No module named django.core.management > > Are you missing vendor libs, or are we missing some instructions that would > make the above command work? Yes, I bet that if you do `ls sheriffs/vendor` you'll see that it's empty. That's because you need to use the --recursive flag when checking out. Just try: `cd sheriffs; git submodule update --init --recursive`
curious as to why you have settings in /settings/local.py whereas all of the rest of our playdoh apps use /settings_local.py ??
(In reply to Corey Shields [:cshields] from comment #23) > curious as to why you have settings in /settings/local.py whereas all of the > rest of our playdoh apps use /settings_local.py ?? It's an improvement I'm working on convincing the rest of the webdev team to adopt. The advantages are numerous: * no more hard coded dependency on "local_settings.py" inside manage.py. Being explicit is always better. * A sensible place to put more custom settings file like "settings/local_bug88888.py", "settings/local_mysqlcluster.py" etc. * I'm able to run "settings/local_test.py" which is geared towards running tests faster and to be run over and over. * Generally ability to override "--settings" to ./manage.py I believe both wenzel and jsocol like it (after some demos) but I haven't forced it upon playdoh yet.
Ok.. at any rate, we are seeing a settings import issue: [Tue Aug 09 13:31:30 2011] [info] mod_wsgi (pid=2829): Create interpreter 'sheriff-dev.allizom.org|'. [Tue Aug 09 13:31:30 2011] [info] [client 10.8.33.248] mod_wsgi (pid=2829, process='sheriff-app', application='sheriff-dev.allizom.org|'): Loading WSGI script '/data/www/sheriff-dev.allizom.org/sheriff-app/wsgi/playdoh.wsgi'. [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] mod_wsgi (pid=2829): Exception occurred processing WSGI script '/data/www/sheriff-dev.allizom.org/sheriff-app/wsgi/playdoh.wsgi'. [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] Traceback (most recent call last): [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/handlers/wsgi.py", line 250, in __call__ [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] self.load_middleware() [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/handlers/base.py", line 39, in load_middleware [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] for middleware_path in settings.MIDDLEWARE_CLASSES: [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/utils/functional.py", line 276, in __getattr__ [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] self._setup() [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/conf/__init__.py", line 40, in _setup [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] raise ImportError("Settings cannot be imported, because environment variable %s is undefined." % ENVIRONMENT_VARIABLE) [Tue Aug 09 13:31:31 2011] [error] [client 10.8.33.248] ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined. [Tue Aug 09 13:31:31 2011] [debug] mod_headers.c(768): headers: ap_headers_error_filter()
playdoh.wsgi fixed now. I managed to get the site up and running in linux with apache2 using this playdoh.wsgi Sigh! Why this stuff is weird. Never really done Apache + django. Why aren't we using Nginx on the web heads?
(In reply to Peter Bengtsson [:peterbe] from comment #26) > playdoh.wsgi fixed now. I managed to get the site up and running in linux > with apache2 using this playdoh.wsgi > > Sigh! Why this stuff is weird. Never really done Apache + django. Why aren't > we using Nginx on the web heads? Because Apache works just fine. If we run 50 other sites with Apache and mod_wsgi just fine with no issues, I don't see why we need nginx to run something else. If you have a substantial performance improvement by using nginx, maybe we can poke. With all the other work that we have right now, it would be really low priority to figure out if we want to switch everything to nginx.
(In reply to Shyam Mani [:fox2mike] from comment #27) > (In reply to Peter Bengtsson [:peterbe] from comment #26) > > playdoh.wsgi fixed now. I managed to get the site up and running in linux > > with apache2 using this playdoh.wsgi > > > > Sigh! Why this stuff is weird. Never really done Apache + django. Why aren't > > we using Nginx on the web heads? > > Because Apache works just fine. If we run 50 other sites with Apache and > mod_wsgi just fine with no issues, I don't see why we need nginx to run > something else. > I know I know. Just airing some frustration with me not knowing Apache anymore. I used to, a long time ago, before Django. > If you have a substantial performance improvement by using nginx, maybe we > can poke. With all the other work that we have right now, it would be really > low priority to figure out if we want to switch everything to nginx. Performance for Sheriffs? Maybe the day there's a snow sculpture competition in hell :)
(In reply to Peter Bengtsson [:peterbe] from comment #28) > Performance for Sheriffs? Maybe the day there's a snow sculpture competition > in hell :) Haha, epic :) <3
Still seeing an ISE on -dev, did you push your wsgi fixed to the repo? Going to bring Jason up to speed on this project and hand it off to him.
Assignee: shyam → jthomas
ISE? Don't know what that is. The change is here: https://github.com/mozilla/sheriffs/commit/ece3586aa02883ea1fdd13d31d7575206cd4fe12 that change made it work for me running Apache locally. Note: this change is only on the "develop" branch. "master" is still unchanged.
ISE (internal server error).. here is the current error: [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] mod_wsgi (pid=9590): Exception occurred processing WSGI script '/data/www/sheriff-dev.allizom.org/sheriff-app/wsgi/playdoh.wsgi'. [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] Traceback (most recent call last): [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/handlers/wsgi.py", line 273, in __call__ [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] response = self.get_response(request) [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/handlers/base.py", line 169, in get_response [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] response = self.handle_uncaught_exception(request, resolver, sys.exc_info()) [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/handlers/base.py", line 214, in handle_uncaught_exception [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] if resolver.urlconf_module is None: [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/core/urlresolvers.py", line 274, in _get_urlconf_module [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] self._urlconf_module = import_module(self.urlconf_name) [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] File "/data/www/sheriff-dev.allizom.org/sheriff-app/vendor/src/django/django/utils/importlib.py", line 35, in import_module [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] __import__(name) [Tue Aug 23 07:20:36 2011] [error] [client 10.8.33.248] ImportError: No module named sheriff-app.urls
Working on this, have it figured out, almost.
Assignee: jthomas → shyam
Next, I need to have superuser access. (then I can set up other relevant superusers for testing) To do this, log in as the user running it and start `./manage.py shell` >>> from django.contrib.auth.models import User >>> peter = User.objects.get(email__startswith='pbengtsson') >>> peter.is_superuser = True >>> peter.save() Secondly, the Django admin static files need to be routed correctly in Apache. All requests for things like "/admin-media/css/base.css" need to pick up from "<location of git checkout>/vendor/src/django/django/contrib/admin/media" Need any help with that?
First part is done: [root@genericadm.private.phx1 sheriff]# ./manage.py shell Python 2.6.6 (r266:84292, Apr 11 2011, 15:50:32) [GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.contrib.auth.models import User >>> peter = User.objects.get(email__startswith='pbengtsson') >>> peter.is_superuser = True >>> peter.save() >>> [root@genericadm.private.phx1 sheriff]#
I'm genuinely ashamed now. It appears that even though I'm a superuser I'm not able to log in to the admin. On the home page it says "(superuser)" next to my name which is good but when I go to "/admin" I'm thrown the login screen again. I really didn't know this would happen. Arguable a Django "flaw" as a superuser shouldn't be hindered by access rights to Django admin. Would you care to execute these lines too please? >>> from django.contrib.auth.models import User >>> peter = User.objects.get(email__startswith='pbengtsson') >>> peter.is_staff = True # now I should be is_staff and is_superuser >>> peter.save()
(In reply to Peter Bengtsson [:peterbe] from comment #34) > Secondly, the Django admin static files need to be routed correctly in > Apache. > All requests for things like "/admin-media/css/base.css" need to pick up > from "<location of git > checkout>/vendor/src/django/django/contrib/admin/media" > Need any help with that? Done: Alias /admin-media /data/www/sheriff-dev.allizom.org/sheriff/vendor/src/django/django/contrib/admin/media (In reply to Peter Bengtsson [:peterbe] from comment #36) > Would you care to execute these lines too please? > > >>> from django.contrib.auth.models import User > >>> peter = User.objects.get(email__startswith='pbengtsson') > >>> peter.is_staff = True # now I should be is_staff and is_superuser > >>> peter.save() no worries. This is done too.
You're a star!! I can confirm that it works (me being staff and being able to use the django administration). Apart from how to deploy upgrades, can we close this now? Or shall we wait till we have the production server? Perhaps we can wait till we know that we can send emails from the server.
Stage is up, also from the develop branch. https://sheriff.allizom.org/
Prod will be up once we decide on the name and I get an SSL cert.
So, what else needs to be done here? Are we just waiting to decide on the name and get prod up?
Name suggestions: sheriffs.mozilla.org.
+1 from me. Let's get a cert and get it live. Thanks Shyam!
(In reply to Ehsan Akhgari [:ehsan] from comment #42) > Name suggestions: sheriffs.mozilla.org. Any objection to sheriff.mozilla.org? There is only one sheriff for the tree at any given point? Or you guys really like sheriffs? :)
I believe 'sheriffs' is better. Being multiples per day is not at all unlikely. The app definitely allows it. Also, it's a site for sheriffs; "who are the release sheriffs". However, I'll ping Jonathan to see if he has an opinion. Judging by the fact that we're having this discussion, can you set up both and redirect the one we don't use for HTTPS into the redirect?
I don't have a strong opinion, and hence like the idea of a 302 from one to the other. If I tried hard to have an opinion, I'd point out that it's people.mozilla, not person.mozilla, and that it's a tool for sheriffs as a class (swapping spots, maintaining rosters). But I'd have to try really hard, and I wouldn't defend it much. Mostly I like "sheriffs" because I do what Ehsan tells me.
(In reply to Johnathan Nightingale [:johnath] from comment #46) > defend it much. Mostly I like "sheriffs" because I do what Ehsan tells me. In between your reply and Peter's, I felt sorry for asking ;) Anyway, I'll set this up as sheriffs.mozilla.org, sheriff.mozilla.org will 302 to sheriffs and the SSL cert will be for sheriffs.mozilla.org
FWIW, I suggested "sheriffs" because we're going to have at least two types of sheriffs, one for mozilla-central and the other for mozilla-inbound. :-)
Peter, What branch do I use for prod?
(In reply to Shyam Mani [:fox2mike] from comment #49) > Peter, > > What branch do I use for prod? master
[root@genericadm.private.phx1 sheriffs]# git branch -a * develop remotes/origin/HEAD -> origin/develop remotes/origin/base remotes/origin/develop remotes/origin/feature/atom-feed remotes/origin/gh-pages remotes/origin/master [root@genericadm.private.phx1 sheriffs]# git checkout origin/master M vendor Note: checking out 'origin/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 61113a7... Merge branch 'release/2011-08-10.08.11' Does that look right? [root@genericadm.private.phx1 sheriffs]# git branch * (no branch) develop [root@genericadm.private.phx1 sheriffs]# git pull You are not currently on a branch, so I cannot use any 'branch.<branchname>.merge' in your configuration file. Please specify which remote branch you want to use on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details.
New error while setting up prod : [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] mod_wsgi (pid=19083): Exception occurred processing WSGI script '/data/www/sheriffs.mozilla.org/sheriffs/wsgi/playdoh.wsgi'. [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] Traceback (most recent call last): [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/core/handlers/wsgi.py", line 273, in __call__ [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] response = self.get_response(request) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/core/handlers/base.py", line 169, in get_response [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] response = self.handle_uncaught_exception(request, resolver, sys.exc_info()) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/core/handlers/base.py", line 214, in handle_uncaught_exception [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] if resolver.urlconf_module is None: [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/core/urlresolvers.py", line 274, in _get_urlconf_module [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] self._urlconf_module = import_module(self.urlconf_name) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/utils/importlib.py", line 35, in import_module [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] __import__(name) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/urls.py", line 6, in <module> [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] admin.autodiscover() [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/contrib/admin/__init__.py", line 22, in autodiscover [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] mod = import_module(app) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django/django/utils/importlib.py", line 35, in import_module [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] __import__(name) [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] File "/data/www/sheriffs.mozilla.org/sheriffs/vendor/src/django-mozilla-product-details/product_details/__init__.py", line 17, in <module> [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] from product_details import settings_defaults [Fri Sep 30 02:50:20 2011] [error] [client 10.8.33.248] ImportError: cannot import name settings_defaults
I set up a vagrant with a bare ubuntu, installed the deps and used your Apache config. At first I noticed that if there's an error executing a request it will instead raise hell about the fact that there is no "500.html" template to return. So I added a 500.html template and made a release to master. Apart from that I was never able to reproduce the error you got. I might have an idea what might have gone wrong though. Because of the git submodule hell we've walked through, it could be that we have the directory 'django-mozilla-products-details' but it's entirely empty and therefore doesn't have a "settings_defaults.py" file. Just a thought. So, I've upgraded master with a new release and also, if you have errors starting it, you can either add: DEBUG_PROPAGATE_EXCEPTIONS = True to settings/local.py and then you should see the full traceback even with `DEBUG=False` or add `DEBUG=True` and see if all is fine. Hit me up on Monday if it's still giving you grief.
(In reply to Peter Bengtsson [:peterbe] from comment #53) > 'django-mozilla-products-details' but it's entirely empty and therefore > doesn't have a "settings_defaults.py" file. > Just a thought. Not the case [root@genericadm.private.phx1 django-mozilla-product-details]# pwd /data/genericrhel6/src/sheriffs.mozilla.org/sheriffs/vendor/src/django-mozilla-product-details [root@genericadm.private.phx1 django-mozilla-product-details]# tree . ├── LICENSE ├── MANIFEST.in ├── product_details │   ├── __init__.py │   ├── json │   ├── management │   │   ├── commands │   │   │   ├── __init__.py │   │   │   └── update_product_details.py │   │   └── __init__.py │   ├── settings_defaults.py │   └── version_compare │   ├── decorators.py │   ├── __init__.py │   ├── tests.py │   └── utils.py ├── README.md ├── requirements.txt └── setup.py 5 directories, 14 files > So, I've upgraded master with a new release and also, if you have errors > starting it, you can either add: > > DEBUG_PROPAGATE_EXCEPTIONS = True > > to settings/local.py and then you should see the full traceback even with > `DEBUG=False` or add `DEBUG=True` and see if all is fine. Going to try this now.
Okay, so the issue was Bug 687106. I added a .gitkeep and we're all good. https://sheriffs.mozilla.org/ is also up. All future requests (auto-updates/updates/pushes/whatnot) should go into different bugs :) Re-open this one, only if something wasn't setup right.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.