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]>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]] *On Behalf Of > *David Winslow > *Sent:* Thursday, May 05, 2011 4:53 PM > *To:* [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. >
