docker
docker copied to clipboard
geoserver
GEOS-11555: fix installation of extensions in various configurations
With this PR, I want to address the issues GEOS-11555 and GEOS-11258 about some inabilities of the extension installer script.
In my opinion, it should be possible to add community modules also to official images. So, I added a warning message instead of blocking it.
Also, I tried to get rid of the confusion in the naming of the variable INSTALL_EXTENSIONS which was controlling the download behavior. Thus, I introduced a variable DOWNLOAD_EXTENSIONS which controls this and made the INSTALL_EXTENSIONS to really control the installation of extensions.
On one point, I'm not sure: Should we fail the startup when we are unable to download extensions? On one hand, the full functionality might not he available and cannot be detected with any sort of health check and on the other hand, maybe it's better to run without an extension than not run at all.
Sorry for the multiple comments, I should have done it properly as a single review. I thought I had only one quick suggestion :-)
Fixing up the if/else errors and the community plugin installs in the install script seems like a good idea.
One thing that worries me a bit are the extra environment variables. There are a lot already. Could your fix work without the extra environment variables?
DOWNLOAD_EXTENSIONS: if you specify an extension, it should be fine to download it if missing. Why the extra check?COMMUNITY_PLUGIN_BASE_URL: a variable in the bash script is probably handy, but I don't think it needs to be configurable?
DOWNLOAD_EXTENSIONS is basically the functionality from the former INSTALL_EXTENSIONS variable to disable the download. This will prevent some errors when run in an environment where the geoserver has no internet access.
COMMUNITY_PLUGIN_BASE_URL allows changing the server for the build artifacts but keep the logic of the structure underneath it.
I BTW missed one ;-))
It could make sense to split them into multiple tables to get some clarity and better overview. Suggesting Geoserver, Tomcat, Extensions
I would be very unhappy with installing community modules into a release intended for production - the point of them is to get feedback on snapshot / nightly build releases to support development. If people want to use extensions in production - stop messing around and fund / complete them.
Really we are already pushing our luck distributing these as nightly builds as they have not been given to the project steering committee for review and publication yet.
I would be very unhappy with installing community modules into a release intended for production
Maybe this is a misunderstanding? I don't think there is any intention to build community plugins into images. One intention of this PR is to optionally allow users to include experimental community plugins on startup/boot time of the container
I would be very unhappy with installing community modules into a release intended for production
Maybe this is a misunderstanding? I don't think there is any intention to build community plugins into images. One intention of this PR is to optionally allow users to include experimental community plugins on startup/boot time of the container
Yes - but only when testing a nightly build please (we do not want to mix a release image with community plugins).
aside: I am considering a proposal to change the policy and make a distribution that includes community plugins as a "tech preview" or something. But until that time we do not have permission to distribute this stuff for production - instead they are shared with the public by the individual developers seeking support/funding.
When ready the developer will provide to geoserver project for IP review and distribution as part of GeoServer.
I would be very unhappy with installing community modules into a release intended for production - the point of them is to get feedback on snapshot / nightly build releases to support development.
This position is your personal ideology Jody, but has nothing to do with the GeoServer project at a large. Since community module existed, users have been free to install community modules in releases as they pleased, in their bin, win installers and war packages.
In the docker image as it stands, an artificial limitation has been added. My suggestion is simple: stop treating users as babies. Mixing release and community modules can result in a GeoServer not starting any longer, it is possible and it has actually happened... but as long as the users are made aware of the risks (stick it in bold font in the docs) it's fine. No need to be patronizing.
What's the latest on this one? After a fair amount of work in October and November of last year and some good discussion on ideology vs practicality of testing community extensions in the container this PR seems to have gone quiet.
@spike83 or @buehner is there something I can contribute to help get this one merged?
@mbheinen I think what we need is a proposal as this is an on going point of friction.
I also feel a bit bad because I am reporting the policy as I understand it; and am not against changing to something better.
Rather than talk - here is a proposal for discussion: https://github.com/geoserver/geoserver/wiki/GSIP-233