We do not need an unmodified version of GeoServer as far as I know. I was just curious if we can get GeoServer, including updates, etc., from geoserver.org or if we should use the GeoNode build.
Thanks, Christian From: [email protected] [mailto:[email protected]] On Behalf Of David Winslow Sent: Friday, May 06, 2011 9:54 AM To: [email protected] Subject: Re: [geonode] GeoNode stability and the 1.1 release series Yes, we need to use a custom build of GeoServer in order to allow GeoServer to respect Django's user system instead of its own. If you want to talk about how to make GeoNode work with an uncustomized GeoServer we can have that discussion, but I am not convinced it is a big problem: apart from ignoring the security/ subdirectory of the datadir, GeoNode's GeoServer reads the same configuration files. If you do need an unmodified GeoServer, could you explain a bit more about why that's the case? -- David Winslow OpenGeo - http://opengeo.org/ On Fri, May 6, 2011 at 9:45 AM, Spanring, Christian <[email protected]<mailto:[email protected]>> wrote: Thanks David, that sounds fantastic! One quick question: will GeoNode 1.1 still depend on a custom build of GeoServer (as 1.0) or will 1.1 be able to use a regular GeoServer 2.1 build? Christian From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of David Winslow Sent: Thursday, May 05, 2011 4:53 PM To: [email protected]<mailto:[email protected]> Subject: [geonode] GeoNode stability and the 1.1 release series Hi all, We've already mentioned this in passing to some folks on this mailing list, but just to officially publicize it: we are no longer planning any further releases from the GeoNode 1.0 series. The PSC has discussed this and the next release will be 1.1-beta. The main reason for this decision is that investigations into the stability of GeoNode have reached a point where the most promising options open to us are reliant on the 2.1.x release series of GeoServer (two examples being the GWC integration which greatly decreases GeoNode's resource consumption, and the control-flow module which also reduces resource consumption (in a different way.) However, the features already implemented on the 1.1 release series are already compelling: * GeoServer 2.1 (many improvements including better raster handling and tight GeoWebCache integration) * UI Improvements (previously intended as the main improvement for the 1.0.1 release.) * Improved GeoNode security system (caching, more reliable technique for overriding GeoServer's builtin security) * Performance improvements in the gsconfig Python module used for syncing the Django and GeoServer layer info * Cookie-awareness for OWSLib (a cookie workaround is already implemented in GeoNode, but if the patch submitted to OWSLib is accepted in time then we will be using "native" cookie support) * The upload functionality in GeoNode will be "refactored" providing better reliability and, importantly, error reporting to assist troubleshooting. Thanks to the Risiko team for these improvements. * Upload-to-PostGIS functionality in the upload form (gsconfig already has support for this and we expect a patch for the GeoNode code that uses it before the beta release. Thanks to the Worldmap team for this.) * Improved Unit and Integration testing suites for the Django components of GeoNode, including a Continuous Integration<http://en.wikipedia.org/wiki/Continuous_integration> server to ensure that all changes that go into the GeoNode core are tested, regardless of potentially forgetful developers. We would like to put the release out after the upcoming roadmapping summit to be held in Washington DC. It is tentatively scheduled for May 27. Ariel, Seb, and I will be sprinting on "sprucing up" the synth branch in anticipation of the release during the week of May 16 (right before the summit.) In the interim, there are some configuration changes that can be made on GeoNode 1.0 installations to improve their stability, although even with these changes we have seen some outages. We'll provide a more detailed writeup soon but in short: * There is a patch available which greatly improves the way that the Django component communicates with GeoNetwork. * Constraining the number of concurrent requests GeoServer will attempt to serve simultaneously will help to avoid OOM exceptions. * Some additional configuration can greatly improve the speed with which GeoServer handles requests, allowing it to have fewer concurrent requests (each request spends less time being handled so fewer of them must be handled at a time for the same request volume.) There is also an experimental branch of gsconfig.py which reduces internal traffic within GeoNode. This is a drop-in replacement for the gsconfig module included with GeoNode 1.0, but is not as well-tested (unit test coverage is the same but it hasn't been tested much "in the field"). I would be interested in reports from any users who try this out. It is a 100% reversible modification so if it doesn't work for you it is straightforward to switch back. Again, we will be providing detailed instructions for applying these changes; they just have not yet been written up. -- David Winslow OpenGeo - http://opengeo.org ________________________________ Please be advised that the Massachusetts Secretary of State considers e-mail to be a public record, and therefore subject to the Massachusetts Public Records Law, M.G.L. c. 66 ยง 10.
