Django on EB: Config settings not carried over to second environment #1087

Closed
simonwhitaker opened this Issue Oct 29, 2012 · 7 comments

Comments

Projects
None yet
4 participants

I followed the instructions here to get a Django app running successfully on Elastic Beanstalk.

I then created a second environment on the same application (for beta testing) and deployed the latest version of the app to this environment, all using the EB control panel at control.aws.amazon.com. This deployment fails however, and I see the following error in my events tab:

Your WSGIPath refers to a file that does not exist.

WSGIPath is specified in .ebextensions/.config, which is checked into Git and hence part of the Git-deployed version that I'm trying to install. It's set correctly to [django-app-name]/wsgi.py, and works fine in my primary environment.

However, if I snapshot the logs for my secondary environment I see this error:

2012-10-29 15:41:57,589 [INFO](2635 MainThread) [directoryHooksExecutor.py-28] [root directoryHooksExecutor info] Output from script: 2012-10-29 15:41:57,577 ERROR The specified WSGIPath of "application.py" was not found in the source bundle

WSGIPath is set to 'application.py' rather than [django-app-name]/wsgi.py.

Any idea why my secondary environment isn't using the values in .ebextensions/.config? How can I remedy this?

(Note: I'm reporting this here as advised by Mitch Garnaat. Hope I've got the right place!)

Owner

jamesls commented Oct 29, 2012

Hi, could you elaborate on how you're creating/deploying the second environment? I'm trying to reproduce but I'm not able to. So once I have a working first environment, I then:

  • Went to the console and clicked Launch New Environment.
  • Specified a specific version under "Select an existing application version".
  • On the configuration tab, enter any additional config info.
  • Clicked finish.

The wsgi path was then set correctly and the environment came up successfully.

Also, for Beanstalk/python container issues, I think it'd be easier to track on the AWS Elastic Beanstalk forums (I'm also watching those forums as well).

I was using the eb command-line tool.

$ eb init

I hit return to keep all the values the same, with the exception of the environment name.

Then I ran:

$ eb start

That initiated the new environment with the standard demo app installed (i.e. the one in this screenshot). Then I went into the console and chose "Deploy a Different Version", and chose the most recent git-[sha1]-[numeric] entry.

Once that deployment finished the console was showing "Successfully running version git-7de136a3259f314947e875f9bb814c182e6b7ba0-1351507932717" next to the environment, but when I visited the URL I was still seeing the demo app, and in the Events tab for my environment I was seeing the error mentioned earlier about the WSGIPath being invalid.

(I can see now that where I said the second environment was set up "all using the EB control panel" in my original issue description, that was incorrect and misleading. Sorry.)

Owner

jamesls commented Oct 31, 2012

Ah ok thanks for the clarification, I think I see what's going on.

As to why you're seeing this issue with your second environment and not your first environment, I believe it's because of an issue with eb. Short answer, to fix your problem I would first edit the .elasticbeanstalk/optionsettings file and remove the line specifying the WSGIPath:

[aws:elasticbeanstalk:container:python]
WSGIPath = application.py

Then if you recreate a new environment with "eb start", everything should work properly.

Longer version if you're interested: Elastic Beanstalk has this concept of "Option Settings", and they can currently be specified in two ways:

  • Via the Elastic Beanstalk API (note the OptionSettings params in the CreateEnvironment API)
  • Via a config file you place in your application source bundle (e.g. .ebextensions/app.config).

If a specific option setting is specified both via the API and the *.config file, then the option specified in the API takes precedence. "eb start" will read the .elasticbeanstalk/optionsettings file and then make a "CreateEnvironment" API call with the Option Settings as specified in .elasticbeanstalk/optionsettings, so anything in .elasticbeanstalk/optionsettings will "win." This is why I'd recommend that, at least for any options specified in the .ebextensions/*.config file, you remove them from .elasticbeanstalk/optionsettings. The reason you didn't have this problem with your first environment is that the .elasticbeanstalk/optionsettings is not created as part of "eb init". I believe that once you run "eb start" for the first time it will write out .elasticbeanstalk/optionsettings.

The Elastic Beanstalk team (who maintains the eb cli) are aware of these issues, and I'll follow up with them again.

Hope this helps.

Thanks James – thorough explanation much appreciated!

@jamesls jamesls closed this Nov 15, 2012

lebsral commented Nov 18, 2012

Hi,

I'm having a very similar problem. Whenever I try to delete the
WSGIPath=application.py
from .elasticbeanstalk/optionsettings it just comes right back after I :eb start

then i have the same problem all over again.

Suggestions?

TIA

Lars

@ghost

ghost commented Dec 12, 2012

I noticed that WSGIPath gets set to application.py even when I run eb stop
Also make sure that your .ebextensions/python.conf contains the correct WSGIPath.

I haven't figured out a fool-proof way to solve this issue. I just delete the entire optionsettings file, and that seems to fix things.

My .elasticbeanstalk folder in the root of my repo is in my .gitignore, so it doesn't get passed. My .ebextensions/app.conf file has the option settings i.e.

option_settings:
    - namespace: aws:elasticbeanstalk:container:python
      option_name: WSGIPath
      value: site/ebtest/wsgi.py
    - namespace: aws:elasticbeanstalk:container:python:staticfiles
      option_name: /static/
      value: site/ebtest/static/
    - option_name: DJANGO_SETTINGS_MODULE
      value: settings_prod

But now when I deploy I get the "Your WSGIPath refers to a file that does not exist." error, and its looking for application.py and not the wsgi.py I have specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment