Re: Geonode geoserver plugin (was Re: [geonode] GeoNode stability and the 1.1 release series)

[David Winslow]

This topic seems more appropriate for the development list than the users one.

On Sun, May 8, 2011 at 9:27 AM, Ariel Nunez <ingenie...@gmail.com> 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?

 

No, for three reasons (that I can think of right now.)

• The GeoNode extensions include more than one .jar to do what they do (third-party libraries for json parsing etc.)  This is easy enough to deal with though, we just have to configure the build to include them when producing the .zip archives for "community releases."
• The GeoServer that we ship for use with GeoNode includes more than just the custom GeoNode extension - the mapfish printing module is a good example of a community module that wasn't written specifically for GeoNode, but which we rely on.
• Switching out the security system requires modifying some other files besides the web.xml (and it requires actually modifying them, you can't just set an environment variable.) 

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 all for separating the sources for the geoserver-based components of geonode from the django-based ones.  But I think we can do that without moving them into GeoServer SVN.  I also think that the GeoServer community will not be very receptive of the idea of including functionality that is only useful for GeoNode in the default distribution, and I also don't think it's a very good idea.

If it's necessary to allow deployers of GeoNode to upgrade existing GeoServers with GeoNode functionality it is quite possible for us to provide a zip archive containing jar files (similar to the ones currently produced for GeoServer extensions and community modules) as an alternative to downloading the full GeoServer-with-GeoNode-stuff that we distribute now.  Moderately maven-savvy developers can actually already produce these from the sources with a little elbow grease.

However, GeoServer extensions generally rely on APIs that are not stable between releases (sometimes even within minor versions) so if we distribute an extension then we are inviting a new class of deployment issues where someone unfamiliar with the project tries to install GeoNode and on top of an existing GeoServer 1.7 installation.  So I'd prefer to stick with the pre-built one for the time being.

I also think that we should hold off on reorganization of the repository until after 1.1 beta comes out (at least on synth/master, of course feature/experimental branches are fair game.)

--

David Winslow

OpenGeo - http://opengeo.org/

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: geo...@librelist.com [mailto:geo...@librelist.com] On Behalf
>> Of David Winslow
>> Sent: Friday, May 06, 2011 9:54 AM
>> To: geo...@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
>> <CSpa...@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: geo...@librelist.com [mailto:geo...@librelist.com] On Behalf
>> Of David Winslow
>> Sent: Thursday, May 05, 2011 4:53 PM
>> To: geo...@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
> gro...@opengeo.org
> Expert service straight from the developers
>
>