1071600 - Clean up wsgi files

Status: RESOLVED INVALID

(Socorro :: Webapp, task)

Description

[Peter Bengtsson [:peterbe]]

1) We have two files in ./webapp-django/wsgi/. One called socorro-crashstats.py and one socorro-crashstats.wsgi. 
We should just need one. 

2) We should use the new API for getting an `application` object. The old way is deprecated in modern version of Django. Instead of:
  
    import django.core.handlers.wsgi
    application = django.core.handlers.wsgi.WSGIHandler()

the new way is:

    from django.core.wsgi import get_wsgi_application
    application = get_wsgi_application()

Comment 1

[Peter Bengtsson [:peterbe]]

What does our puppet apache conf say in terms of wsgi?

Comment 2

[Daniel Maher [:phrawzty]]

(In reply to Peter Bengtsson [:peterbe] from comment #1)
> What does our puppet apache conf say in terms of wsgi?

The current Apache configuration that is active on the Prod webheads contains the following line:

    WSGIScriptAlias / /data/www/crash-stats.mozilla.org/socorro/webapp-django/wsgi/socorro-crashstats.wsgi process-group=crashstats_prod application-group=crashstats_prod

Which indicates that socorro-crashstats.wsgi is, indeed, the one being used.

Comment 3

[Peter Bengtsson [:peterbe]]

PR https://github.com/mozilla/socorro/pull/2393

Comment 4

[Robert Helmer [:rhelmer]]

The reason we have a .py is because gunicorn requires it. We want to deprecate and move away from the .wsgi files in fact.

Comment 5

[Peter Bengtsson [:peterbe]]

So, what to do? Change apache puppet to use the .py and *then* delete the socorro-crashstats.wsgi file?

Comment 6

[Robert Helmer [:rhelmer]]

(In reply to Peter Bengtsson [:peterbe] from comment #5)
> So, what to do? Change apache puppet to use the .py and *then* delete the
> socorro-crashstats.wsgi file?

Yes - sorry I didn't follow up on this myself.

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to Robert Helmer [:rhelmer] from comment #6)
> (In reply to Peter Bengtsson [:peterbe] from comment #5)
> > So, what to do? Change apache puppet to use the .py and *then* delete the
> > socorro-crashstats.wsgi file?
> 
> Yes - sorry I didn't follow up on this myself.

Production Apache doesn't seem to be in SVN/puppet anymore BTW, so we need to proceed carefully.

Comment 8

[Robert Helmer [:rhelmer]]

(In reply to Robert Helmer [:rhelmer] from comment #7)
> (In reply to Robert Helmer [:rhelmer] from comment #6)
> > (In reply to Peter Bengtsson [:peterbe] from comment #5)
> > > So, what to do? Change apache puppet to use the .py and *then* delete the
> > > socorro-crashstats.wsgi file?
> > 
> > Yes - sorry I didn't follow up on this myself.
> 
> Production Apache doesn't seem to be in SVN/puppet anymore BTW, so we need
> to proceed carefully.

Or at least not in the bit of SVN I have access to - I just mention it because it bit me last time I had to make a WSGI-related Apache change.

Comment 9

[Daniel Maher [:phrawzty]]

(In reply to Robert Helmer [:rhelmer] from comment #7)
> Production Apache doesn't seem to be in SVN/puppet anymore BTW, so we need
> to proceed carefully.

The *Stage* Apache config is found in the "socorro" module:

MD5 (./modules/socorro/files/stage/web/etc-httpd/domains/crash-stats.allizom.org.conf) = 1bab9b2432e0cfbea2dbf58baf8e0215

[[e-mail]1 ~]$ md5sum /etc/httpd/mozilla/domains/crash-stats.allizom.org.conf
1bab9b2432e0cfbea2dbf58baf8e0215  /etc/httpd/mozilla/domains/crash-stats.allizom.org.conf


The *Prod* Apache config is found in the "webapp" module:

MD5 (./modules/webapp/files/crashstats/etc-httpd/domains/crash-stats.mozilla.org.conf) = 1d7319d00999b60616a1f72604df0abd

[[e-mail]1 ~]$ md5sum /etc/httpd/mozilla/domains/crash-stats.mozilla.org.conf
1d7319d00999b60616a1f72604df0abd  /etc/httpd/mozilla/domains/crash-stats.mozilla.org.conf


But be careful!  There's also an *unused* Stage config in the "webapp" module :

MD5 (./modules/webapp/files/socorro-stage/web/etc-httpd/domains/crash-stats.allizom.org.conf) = e6b0e93d3ebc76b7888f0d3661ac0623


tl;dr It's a hot mess.

Comment 10

[Daniel Maher [:phrawzty]]

Closing this out since we're abandoning PHX and moving entirely to AWS with brand-new infra and deployment structures (bug 1118288).

Comment 11

[Robert Helmer [:rhelmer]]

I think we still want to fix this, but we need to be out of PHX in order to do so.

Comment 12

[Peter Bengtsson [:peterbe]]

We're no longer using apache. And we've changed the wsgi file to work with Django 1.7

Now we just have the annoying thing that there are two wsgi files
https://bugzilla.mozilla.org/show_bug.cgi?id=1217184