Support #7155

How to add AquacultureAtlasGeneration scope with AAPS Geoserver

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

Status:RejectedStart date:Feb 17, 2017
Priority:UrgentDue date:
Assignee:Fabio Sinibaldi% Done:

0%

Category:-
Infrastructure:
Milestones:
Duration:

Description

Currently in #5828, i'm able to use my AAPS (AquacultureAtlasGeneration VRE) security token to upload data in workspace with HomeLibrary API.

I need to use the same token to then use the Data-Transfer library to transfer the uploaded data to Geoserver, using this service: https://geoserver1-spatial-dev.d4science.org/data-transfer-service/gcube/service

I'm not able to do it, is it because of AAPS scope not registered for the above endpoint? or because one is dev, and the other is prod?
If possible could add AquacultureAtlasGeneration scope for the above Data-Transfer endpoint.

Thanks in advance for your support, so i can report ASAP on #5828 and provide the material to use to CLS.


Related issues

Related to BlueBRIDGE - Project Activity #5828: Evaluate feasibly to publish Spatialite layer in GeoServe... Closed Dec 02, 2016
Related to BlueBRIDGE - Task #7169: Install AAPS production GeoServer with spatialite plugin ... Closed Feb 20, 2017

History

#1 Updated by Emmanuel Blondel almost 3 years ago

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

#2 Updated by Leonardo Candela almost 3 years ago

  • Assignee set to Fabio Sinibaldi

My feeling is that the service you are trying to use is not the "right" one (from the URL it seems a dev service while you are using a token for a production environment).

In general, you should not rely on fixed URLs for services rather you should first discover the right one to use in each context by querying the IS. This is true for any service you are interfacing with.

BTW I'm adding @fabio.sinibaldi@isti.cnr.it and @roberto.cirillo@isti.cnr.it that can certainly be more helpful than me :)

#3 Updated by Emmanuel Blondel almost 3 years ago

Thanks Leonardo, it is also my feeling, btw i have been using a token from RPrototypingLab to use this dev Data-Transfer service, that's why i have a doubt. This geoserver (specifically targeting AAPS - because of Spatialite needs) + the Data-Transfer endpoint were set-up as "dev", but we need to use it together with the AquacultureAtlasGeneration VRE (AAPS), so it would be good to have it for prod instead.

IMHO, although it is generally better to have 2 environments (dev/prod) or better 3 (dev/qa/prod), here it's quite an "heavy" approach.. what we do are simple publication tests, and these can be handled in the same geoserver instance, e.g. by using a specific "test" datastore that we remove once tests are ok. If it's not ok for you, then we will need to have another instance of Geoserver, enabling Spatialite with same characteristics, but if possible, please, consider to turn on the current instance as production (so we move forward quickly on AAPS VRE needs), Same for the Data-Transfer REST endpoint configured on this machine, and create similar environment for future devs/tests.

Many thanks

#4 Updated by Fabio Sinibaldi over 2 years ago

  • Status changed from New to Rejected

Hi Emmanuel,
sorry but we can't just make a development instance a production one because of lots principles : the machine configuration and capabilities, the services configuration, the name itself, and moreover the data published in that instance. Also, it uses databases from development that are used by other applications as well ..
So it's far better to enable the features in a production instance (or all) or create a new one.

I understand that the approach to operate on different environment seems an overkill to you, but you need to understand that for stability of the infrastructure, every change needs to be checked / tested. Especially if we're talking about a shared application like GeoServer. If it wasn't so, every community would request operations in production and basically prevent everyone from exploiting the infrastructure itself.
What you asked wasn't just a publication test, because involved different actions in configuring the GeoServer, the SmartGear, the DataTransfer, and various restarts.
Can you imagine if all activities reported in https://support.d4science.org/issues/5828 were performed in production?

Now, since you think we achieved a stable point, we can port these changes in production so you can operate with the GeoServers which are properly operating in your production scope.
I'm creating the task #7169 for this purpose.

#5 Updated by Emmanuel Blondel over 2 years ago

Thanks, do it according to your procedures.

#6 Updated by Pasquale Pagano over 2 years ago

  • Related to Task #7169: Install AAPS production GeoServer with spatialite plugin & DataTransfer service added

Also available in: Atom PDF