How to add AquacultureAtlasGeneration scope with AAPS Geoserver
|Status:||Rejected||Start date:||Feb 17, 2017|
|Assignee:||Fabio Sinibaldi||% Done:|
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.
#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.
#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.
#4 Updated by Fabio Sinibaldi over 2 years ago
- Status changed from New to Rejected
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.