MasterSite vs GeoSite

[matthewhanson]

For Landscape Portal, each individual site will be on it's own server. The MasterSite will be on it's own server, along with the database used by all the sites.

However, GeoSites needs access to the MasterSite settings file, templates, and static files*.

One approach is to treat the MasterSite as it's own project and install it as such on each machine.

Another approach would be to use a shared storage space to store the MasterSite files (and also server static files from).

• static files can be discussed separately, but by having different web servers means we have multiple copies of assets on each server. Maybe not worth discussing near term.

[simod]

Uhm, what's the advantage of having every site on it's own server if the database and geoserver live on the MasterSite?

[matthewhanson]

I'm not sure, but they want it configured like this, to keep each site physically separate. I don't think there's really an advantage.

GeoServer is also on it's own server.

Servers

• MasterSite and database(s)
• GeoServer
• Each site

[simod]

It sounds a bit inefficient to have just the python running on a server and all the data elsewhere. That will generate a lot of slow connections. I thought that for the GeoSite they would have used virtualhosts. also because from different servers they need to deploy different GeoNodes that could be avoided in the other case.

[matthewhanson]

I agree. My preference would be to have all the servers together on a machine. Geoserver on it's own, and the datastore on the same machine as geoserver, and the django db on the web server. On Jun 18, 2015 9:16 AM, "Simone Dalmasso" notifications@github.com wrote:

It sounds a bit inefficient to have just the python running on a server and all the data elsewhere. That will generate a lot of slow connection. I thought that for the GeoSite they would have used virtualhosts. also because from different servers they need to deploy different GeoNodes that could be avoided in the other case.

— Reply to this email directly or view it on GitHub https://github.com/terranodo/landscapeportal/issues/7#issuecomment-113152113 .

[eomwandho]

Which implementation was agreed on? having the geosites under the master or on individual VM.

[matthewhanson]

@eomwandho Right now they geosites and master are on one server, which is the preferred method. Please let us know if this doesn't meet your requirements.

[matthewhanson]

For reference here's what I posted in slack:

All of the sites have a lot of shared components - GeoNode for one, but also all other dependencies and potentially templates, static files, and settings - all of the sites have some set of shared settings files, with site specific settings in it's own.

Because of this interdependence, it would greatly increase the administration efforts, since it is not just the DB that links these sites, but static files and templates. Effort would need to be made to keep those files synchronized or use some sort of shared storage and upgrades will need to be done across multiple machines at once.

Is the separation of sites on VMs a hard requirement? We would suggest that all the sites be hosted together. The dev server is currently set up with a master site and site2

[eomwandho]

If putting the geosites and master on same machine, would reduce the amount of work the we will support that option also.

[simod]

@eomwandho yes it would and also increase the performances as we would avoid database hits across different machines.