I'd like us to move this thread to the development list (this sort of planning discussion isn't really appropriate for the users list.)
If anyone from this list is interested in following the discussion, you can see the web archive of the thread on the development list at: https://groups.google.com/a/opengeo.org/group/geonode-dev/browse_thread/thread/130e91c005f783c2# -- David Winslow OpenGeo - http://opengeo.org/ On Sun, May 8, 2011 at 9:27 AM, Ariel Nunez <[email protected]>wrote: > Thanks for the explanation Gabriel. > > When those changes are integrated to the 2.1.x branch would it be > posible to download a nightly build from geoserver.org and then just > drop the geoserver-geonode.jar plugin in the right directory to do the > auth override? > > If that is the case, do you think it would make sense to put such a > plugin as a community module in GeoServer and take it out of the > github repo? In my humble opinion we could start with a community > module, then in a few months try to become an extension and find our > way into the default extensions bundled with GeoServer, so that people > can enable GeoNode compliance with just setting the GEONODE_BASE_URL > in web.xml or the environment. > > I am going to think more about this and try to come up with a more > complete proposal, but would love to hear feedback from the community. > > Ariel. > > > The situation will be reverted to depend on vanilla geoserver 2.1.x > > branch once it's open for new developments again (i.e. after the 2.1.0 > > release of geoserver, which should be next week). > > > > Does that answer your question? > > > > Cheers, > > Gabriel > >> > >> > >> > >> 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]> 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 > >> 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. > >> > >> > >> > >> > >> > > > > -- > > Gabriel Roldan > > [email protected] > > Expert service straight from the developers > > > > >
