ixc / ixc-project-template

Bare-bones skeleton project template, for use with the `django-admin.py startproject` command.
1 stars 0 forks source link

Ansible integration #14

Open mjog opened 9 years ago

mjog commented 9 years ago

ICANHASMERGE?

mrmachine commented 9 years ago

Just a few questions:

1) Why {{ project_name }}/app/{{ repo_name }} vs. just {{ project_name }}/{{ repo_name }} or {{ project_name }}/app? I think probably the latter is best - why do we care what the repo name is, just make app the working copy for brevity and consistency?

2) Why localhost vs 127.0.0.1? This seems a no-op at best (just a name lookup against /etc/hosts), but to specify all interfaces (e.g. during development) it's 0.0.0.0 (no corresponding name). An IP then seems more consistent?

3) Should the system-supervisor tag be django-supervisor instead? Previously I think these tags indicated which services would be added to the system-level (and only) supervisor instance. Is the new tag just indicating that the django-supervisor management command will be added to the system-level supervisor?

mrmachine commented 9 years ago

Oh, and would SUPERVISOR_ADDRESS more directly match the setting we are pulling from the env? Just thinking if/when more deployment settings are added, using the same name in the env and settings module might be good.

mjog commented 9 years ago

The per-service hierarchy I have settled on is:

/ixc
  |-- {{service}}
  |    |-- app
  |    |    |-- {{repo}}
  |    |    `-- venv
  |    |-- etc
  |    |-- log
  |    `-- media
   .

Although it isn't quite the case at the moment, I'm planning on making app the only directory writable by the ixc user. I can't collapse the repo down a level, otherwise the ixc user would need write access to {{service}}, which will let users and intruders break things.

Using localhost is human readable, a trivial lookup, and otherwise identical to using 127.0.0.1. It's got nothing to do with 0.0.0.0 - if you want that, then use that, but you don't, so use localhost.

The tag is system-supervisor since if present, on deploy the app will be restarted in the system-wide instance of supervisor, not the app-local one. Doesn't have any other effect.

SUPERVISOR_ADDRESS is incorrect, since it's not an address that supervisor uses. Currently, it is passed to gunicorn, but using LISTEN_ADDRESS makes it both obvious what it is used for and decoupled from gunicorn.

I just pushed a change removing supervisor config from local.py - the default should cover all common use cases for both development and deployment, and people should be discouraged from messing with it.

markfinger commented 8 years ago

@mrmachine given the move to docker, I gather this is outdated. If so, can you close this?