Task #7538

Deploy patch (JAR) in AAPS Production Geoserver

Added by Emmanuel Blondel over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:Mar 15, 2017
Priority:HighDue date:
Assignee:_InfraScience Systems Engineer% Done:

100%

Category:Default
Sprint:WP04
Infrastructure:
Milestones:
Duration:

Description

The attached JAR (patch for Spatialite REST API upload) should replace the gs-restconfig JAR available in WEB-INF dir of AAPS Production Geoserver. And GeoServer restarted..
Let me know when done

gs-restconfig-2.10.0.jar (264 KB) Emmanuel Blondel, Mar 15, 2017 06:35 PM


Related issues

Related to BlueBRIDGE - Project Activity #5828: Evaluate feasibly to publish Spatialite layer in GeoServe... Closed Dec 02, 2016

History

#1 Updated by Emmanuel Blondel over 2 years ago

  • Related to Project Activity #5828: Evaluate feasibly to publish Spatialite layer in GeoServer with existing tools added

#2 Updated by Pasquale Pagano over 2 years ago

  • Sprint changed from Unsprintable to WP04
  • Assignee set to _InfraScience Systems Engineer
  • Category set to Default

We come to the point that this is not an official released package and we should deploy this jar that is neither officially released nor it is planned to be maintained.

In any other case I would have said that there is not way to run it in production. However, considering the fact that this activity was not well designed at the beginning and it is blocked by this issue, I leave @andrea.dellamico@isti.cnr.it to decide if we can deploy it or not.

#3 Updated by Emmanuel Blondel over 2 years ago

Dear Pasquale, since D4Science supports GeoServer versions with REST API Config (from GeoServer 2.1.x series), the Spatialite upload was supported by GeoServer REST API since the beginning (you can refer to Geoserver documentation). This activity has been designed as it should have been done to fulfil the initial user requirements (including the expressed need to use Spatialite). The identification of a bug is unfortunately the unknown variable of any software-related activity, and we have to compound with that. It doesn't mean that the activity is not well designed (unless they are other reasons to state that). This testing was part of #5828 task. A bug has been identified, we have the possibility to fix it instead of bypassing it (with whatever software, gCube or not), which still seems to be the better and more reasonable & sustainable choice. I assume the recommendation I made within FAO team and to CLS to proceed in this way.

For what concern this specific task, I submit this ticket for the production Geoserver essentially because in term of environment, it's the one that is linked to the AAPS Geoserver for which the features are supposed to be built by VRE managers. This said, we have a "test" instance AFAIK, so if you may decide to restrain the task to it (in particular if you have software policies that state and forbid any non-official release third-party dependency in a production runtime resource), and condition the deployment to the production Geoserver / upgrade of the later only and only after the official release of the component in GeoServer.

For what concern the latter statement, pull requests (including backports to 2.11.x and 2.10.x) have been made in GeoServer:
* https://github.com/geoserver/geoserver/pull/2153
* https://github.com/geoserver/geoserver/pull/2154
* https://github.com/geoserver/geoserver/pull/2155

You may also indicate to pause this task and wait for the acceptance of the above pull requests,

Best regards

#4 Updated by Pasquale Pagano over 2 years ago

By saying that the activity was not well-designed I was too strong and you correctly replied to my comment. SpatialLite was not supported by the infrastructure and counting on it was too risky as the reality proved to be. Deploying an artifact that is not yet included in the official release means (and you know it) that we will have troubles in the future if it will not be included since we will not be able to upgrade the technology anymore.
I cannot pause this activity because the VRE activity is delayed already and we cannot continue to accept this delay. If I do it, I have also to raise the issue to the PSC that then has to take management and financial actions against the VRE partners.
So, let's proceed by deploying the patch first in the development instance and then after the test to the production one.

#5 Updated by Andrea Dell'Amico over 2 years ago

  • Status changed from New to In Progress

#6 Updated by Andrea Dell'Amico over 2 years ago

  • % Done changed from 0 to 80

I've installed it in dev. @emmanuel.blondel@fao.org can you check if it works? If so, I'll install into the production server too.

#7 Updated by Andrea Dell'Amico over 2 years ago

  • Tracker changed from Support to Task

#8 Updated by Emmanuel Blondel over 2 years ago

I'm going to check & report here, thanks.

#9 Updated by Emmanuel Blondel over 2 years ago

Thanks Andrea, the patch is functional. I've tested the Spatialite upload through R and Python interfaces. Spatialite data is correctly uploaded, and in line with the behavior explained at http://docs.geoserver.org/stable/en/user/community/spatialite/index.html. That is the spatialite DB file is uploaded to the geoserver data directory.

Note that i've noticed it is not uploaded to srv/geoserver_spatialite/data path initially set-up by your team. For this, FYI, I suspect a misconfiguration of the data directory location or an absence of custom data directory (see http://docs.geoserver.org/stable/en/user/datadirectory/setting.html). Since the default geoserver_data_dir location is still evaluated by the Geoserver application, spatialite files are uploaded there (that is within the Geoserver webapp dir). You may consider moving the Geoserver_data_dir outside the webapp (as good practice), and it will be probably relevant to the work activity on Workspace sync.

I'm going to provide an updated Python script to CLS.

Let me know when it is done on the production Geoserver https://geoserver1-p-spatial.d4science.org/geoserver/

Last but not least: i will keep watching the release of this fix in Geoserver (Cf. above mentioned pull requests). As soon it is merged (with backport on 2.10.x), i will inform you.

#10 Updated by Andrea Dell'Amico over 2 years ago

  • % Done changed from 80 to 100
  • Status changed from In Progress to Feedback

Emmanuel Blondel wrote:

Thanks Andrea, the patch is functional. I've tested the Spatialite upload through R and Python interfaces. Spatialite data is correctly uploaded, and in line with the behavior explained at http://docs.geoserver.org/stable/en/user/community/spatialite/index.html. That is the spatialite DB file is uploaded to the geoserver data directory.

Just installed into production too.

Note that i've noticed it is not uploaded to srv/geoserver_spatialite/data path initially set-up by your team. For this, FYI, I suspect a misconfiguration of the data directory location or an absence of custom data directory (see http://docs.geoserver.org/stable/en/user/datadirectory/setting.html). Since the default geoserver_data_dir location is still evaluated by the Geoserver application, spatialite files are uploaded there (that is within the Geoserver webapp dir). You may consider moving the Geoserver_data_dir outside the webapp (as good practice), and it will be probably relevant to the work activity on Workspace sync.

You are correct. I just changed to /srv/geoserver_spatialite/data in both dev and production.

#11 Updated by Emmanuel Blondel over 2 years ago

  • Status changed from Feedback to Closed

Thanks @andrea.dellamico@isti.cnr.it , it works

#12 Updated by Emmanuel Blondel over 2 years ago

Dear CNR team, about the concern "jar that is neither officially released nor it is planned to be maintained", i confirm that:

  • its maintenance was planned (the requested deliver of this patch included of course the requirement to send it for merge to GeoServer SCM - Cf. above listed Github pull requests)
  • as follow-up: the above pull requests have been merged 3 days ago by GeoServer team (targeting the master + backport for the Geoserver release used here in AAPS VRE)

Also available in: Atom PDF