Re: [geonode] Geonode deploy branch
- From:
- Ariel Nunez
- Date:
- 2010-08-11 @ 16:24
On Wed, Aug 11, 2010 at 11:05 AM, David Winslow <dwinslow@opengeo.org> wrote:
> 1) I don't see anything related to this in the diff. What needed to be
> changed to run the site with geonode.settings?
Moving the registration templates from the capra dir to the geonode one.
> 2) Looking over the diff for this I saw some stuff (like viewer.json) that
> can be dropped entirely instead of ported.
Which other files can be dropped apart from that one?
> 3) Why is this needed?
This is a pony, just a way to have more control over the behavior of
the media serving within Django, specifically in deployment I never
want to serve files with Django, but I want to be able to set DEBUG on
sometimes to see the fancy error page.
It is also the same setting used in the static files app used in Pinax:
http://pinaxproject.com/docs/dev/settings.html#serve-media
> 4) This needs some discussion before pulling into master, as I guess it will
> become the endorsed means of customizing a GeoNode site if we bring it in.
This is the defacto way to customize a Django project, it is used by
Satchmo, Pinax, Django Mingus and many others.
As it stands we would need to choose between importing a
local_settings.py from the main settings file or creating another
settings file and importing geonode's settings at the start.
I like the local_settings.py approach because I can choose to put some
code after that import to reuse the update vars (for example the media
links at the end of the settings file).
The local_settings.py file should be kept outside version control, and
sensible information like database password, email password, etc
should be there.
Ariel
Re: [geonode] Geonode deploy branch
- From:
- Sebastian Benthall
- Date:
- 2010-08-20 @ 20:04
>
> > 3) Why is this needed?
>
> This is a pony, just a way to have more control over the behavior of
> the media serving within Django, specifically in deployment I never
> want to serve files with Django, but I want to be able to set DEBUG on
> sometimes to see the fancy error page.
>
> It is also the same setting used in the static files app used in Pinax:
> http://pinaxproject.com/docs/dev/settings.html#serve-media
I'm finding myself wanting this pony every time I do a redeployment.
It should go into master.
--
Sebastian Benthall
OpenGeo - http://opengeo.org
Re: [geonode] Geonode deploy branch
- From:
- Sebastian Benthall
- Date:
- 2010-08-11 @ 16:18
>
> 4) This needs some discussion before pulling into master, as I guess it
> will become the endorsed means of customizing a GeoNode site if we bring it
> in.
>
2 cents -- My gut is +1 on separating out the local_settings but I have two
questions:
(1) What is the criteria for determining whether a settings should go in
local_settings vs. general site settings?
(2) How would this would work with the make_release process and the
resulting bundle.
(3) What should the default deployment options be for the source code/build?
> On Wed, Aug 11, 2010 at 11:38 AM, Ariel Nunez <ingenieroariel@gmail.com>wrote:
>
>> Hi people,
>>
>> I made a few updates to GeoNode while doing the deployment on the
>> Bank's Amazon Instance.
>>
>> The can be found in this branch:
>> http://github.com/ingenieroariel/geonode/compare/master...deploy
>>
>> And here is a summary:
>>
>> 1. Fixed the codebase to run the website using geonode.settings
>> instead of capra.settings
>> 2. Removed mentions of CAPRA wherever possible
>> 3. Added a new setting called SERVE_MEDIA indicating if Django should
>> serve media or not. Before that we used the DEBUG value.
>> 4. Added a local_settings import to separate deployment options from
>> the main settings file. (We need to create a sample_local_settings.py
>> for people to start off)
>>
>> I would like some feedback about those changes to see if I can merge
>> that branch into master.
>>
>> Cheers,
>> Ariel
>>
>> PD: I plan to both send another email with bugs(after I ticket them) I
>> found while deploying and also write up a document about deploying
>> GeoNode in Ubuntu that will cover setting up Nginx as a frontend
>> proxy, enabling registration, adding an Email backend, adding custom
>> templates to override GeoNode ones (for html/css savvy users).
>>
>
>
--
Sebastian Benthall
OpenGeo - http://opengeo.org
Re: [geonode] Geonode deploy branch
- From:
- Ariel Nunez
- Date:
- 2010-08-11 @ 16:31
> 2 cents -- My gut is +1 on separating out the local_settings but I have two
> questions:
> (1) What is the criteria for determining whether a settings should go in
> local_settings vs. general site settings?
Generic GeoNode settings should be in settings.py, they should work
for a developer machine and be able to run even if local_settings.py
is not defined.
Only the specific bits for a given deployment, like [DATABASE_NAME,
SITE_URL, GEOSERVER_BASE_URL, EMAIL_HOST, ADMINS] should be in
local_settings, we should provide users for a sample of a
LOCAL_SETTINGS file with commented out options and explanations about
them.
> (2) How would this would work with the make_release process and the
> resulting bundle.
The same steps we take to safeguard the production.db file should be
taken to keep the local_settings.py file both private and backed up.
For instance, In my server I have a ~/local dir that contains the
local_settings.py, the sqlite db and the paster .ini file and I keep
them on a private github repo. I use symlinks to put them in the right
places of the filesystem.
> (3) What should the default deployment options be for the source code/build?
Not sure how to answer this, I don't understand the question.
Ariel
Re: [geonode] Geonode deploy branch
- From:
- Sebastian Benthall
- Date:
- 2010-08-11 @ 17:04
>
> > (3) What should the default deployment options be for the source
> code/build?
>
> Not sure how to answer this, I don't understand the question.
Answered it in part (1). Thanks.
+1 on all this.
--
Sebastian Benthall
OpenGeo - http://opengeo.org