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
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: geonode@librelist.com [mailto:geonode@librelist.com] On Behalf Of David Winslow Sent: Thursday, May 05, 2011 4:53 PM To: geonode@librelist.com 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.
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 <CSpanring@mapc.org>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:* geonode@librelist.com [mailto:geonode@librelist.com] *On Behalf Of > *David Winslow > *Sent:* Thursday, May 05, 2011 4:53 PM > *To:* geonode@librelist.com > *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. >
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: geonode@librelist.com [mailto:geonode@librelist.com] On Behalf Of David Winslow Sent: Friday, May 06, 2011 9:54 AM To: geonode@librelist.com 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 <CSpanring@mapc.org<mailto:CSpanring@mapc.org>> 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: geonode@librelist.com<mailto:geonode@librelist.com> [mailto:geonode@librelist.com<mailto:geonode@librelist.com>] On Behalf Of David Winslow Sent: Thursday, May 05, 2011 4:53 PM To: geonode@librelist.com<mailto:geonode@librelist.com> 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.
On Fri, 2011-05-06 at 10:09 -0400, Spanring, Christian wrote: > 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. Ok. GeoNode builds on top of the regular geoserver build, which is deployed to the maven repository every time the geoserver continuous integration server builds it (pretty much every time a commit is made). So what you get in geonode is what's current in GeoServer. Or should be. The current situation for the synth branch is that GeoNode needs some enhancements to the gwc module that are not part of the GeoServer 2.1.0 release, so we're depending on a custom branch that's vanilla geoserver 2.1.x plus the enhancements for the gwc branch. 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: geonode@librelist.com [mailto:geonode@librelist.com] On Behalf > Of David Winslow > Sent: Friday, May 06, 2011 9:54 AM > To: geonode@librelist.com > 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 > <CSpanring@mapc.org> 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: geonode@librelist.com [mailto:geonode@librelist.com] On Behalf > Of David Winslow > Sent: Thursday, May 05, 2011 4:53 PM > To: geonode@librelist.com > 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 groldan@opengeo.org Expert service straight from the developers