D4Science Infrastructure

The WebApp publisher is a process of Dataminer and, as such, all the information about a Web application is stored on the Workspace. Thus, the metadata are there, also the address of the uploaded Web App.

Currently, the application is "installed" on the remote service using the DataTransfer service, which does not support updating. Updating can be requested as a feature to the new DataTransfer service we are developing, so that the user may be able to update the Web App.

On the other hand, I think if it would be safer if a user knew the location of his own Web applications, and this can be done by querying the Workspace. In particular, the Prov-O XML inside a computation folder (or the metadata attached to the folder), contains all the information required. Further, the DataMiner folder contains also the history of the published Web Apps, so that one could also use/link other versions.

Hi, some user experience (IMHO related to the above request, so i put it here.. but please let me know if you prefer it a separate ticket):

• Uploading a zip application to the workspace takes ~ 2s, but publishing the web-app takes 6min. Is there room for improving this? I'm commenting it here, because i suppose that the first publication could take time (instantiate Apache, etc), but this could be much faster to update content of an already existing web-app. Do you confirm?

• Dataminer publisher is very useful, in particular if we trigger it from outside the portal. But (yet another related "support" question, to be seen as complementary user tool): would you have a way to make the shared Apache target www directory available through the workspace? this would improve usability for people that maintain an app (to upload new data, but also to look at published resources, and share with other users)? If you can support this, it would be great.

Thanks in advance for your feedback

Hi Emmanuel, the WebApp is using an old DataTransfer technology we inherited from CERN. Hopefully from the next release, the DataTrasfer service will be replaced by a new service #5549. I'm not sure the performance will increase just from the next release, but we will try it.

On the Workspace, you can already share a link to an application. You should right click on the left hand side tree and select "New Url". For some reason (I don't remember), this feature was hidden and can be accessed only by right-clicking on the tree. I don't know if this answers to your request.

I think it's a different thing (but thanks for the tip). My question was: once we published some web-app to an Apache container, could we have access to this Apache container through the workspace?

Sorry, I don't understand. The Workspace is an online file system, Apache is a server and the Web app a sort of service. What do you mean for a service into an online system? Would like to have access to the local machine file system through a Web application (or have this local file system mirrored on the Workspace)?

Yes it's a file system. But Apache www dir also, they are static resources, wondering if you can map both. That is: to publish/update a web-app, we could do this task at workspace level. In term of usability, it would be more than great, also consider that when updating a web-app we don't need to update everything, but probably 1 or 2 files, e.g. 1 javascript, and 1 CSS stylesheet.

From usability point of view:

• if you use Dataminer from outside, you execute one web-service request to push data
• if you use the portal you have to: access the workspace and upload your webapp zip, go to a VRE with Dataminer, select the publisher algorithm, and upload the full web-app. If we could use the workspace directly (for an existing published webapp) you would just need to upload the updated files.

Last but not least: maybe much convenient for user that maintain web-apps published to Apache (that are consequently 'webmasters'): can they have access to public html dir through SFTP?

More generally (maybe a question for @pasquale.pagano@isti.cnr.it ), i'd like to know if/how these resource admin roles are taken into account in the infrastructure policies? here i point out the need of accessing Apache wwww dir for webmaster role, but i'm sure they are other cases.

Thanks a lot

@gianpaolo.coro@isti.cnr.it you passed this task to us but without any background it's hard to understand what's needed. Which httpd server? Who needs to access it?

Sorry, I did not give explanation because I hoped to be able to discuss this with you in person.

@emmanuel.blondel@fao.org I can give you sftp access in the same way I did for the geoservers. I'm not able to restrict your write access to your applications only, the system was not designed to manage this kind of accesses. Let me know if it's OK for you.

here my two cents on the overall context:
There are 2 main viewpoints to consider behind using (or not) this web-app publisher:
1- basic user who wants to test a web-app online, and with no intention to maintain it behind
2- webmaster that needs to deploy a web-app, but behind who needs to mainain it, either through major upgrade, or small edits

So far, the uses case we covered (PAIM, TunaAtlas, AquacultureAtlas) require to take viewpoint 2, not 1.
We need to deploy a web-app, but be able to maintain it, and one pre-requisite is by essence to keep a persisting URL
Hence:

• if I publish a web-app with the DM web-app publisher. I get a URL build of an UUID. First: having this UUID is quite unappropriate for user. There is a need to customize relative URL. See 1st bullet point in this ticket description
• if I want to update the same web-app I'm not able to do it. Here I don't expect to to have to re-use the DM webapp publisher. Indeed, most of actions after publication will mainly require small edits, just 1 or 2 files changes. So redeploy the complete web-app is not really convenient.

On other aspect, If I understand well, we are not able nor authorized (a matter of policy I assume) to access such published web-app through SFTP, although that would be the most straighforward way to let webmaster do their job.

@andrea.dellamico@isti.cnr.it if you can provide SFTP access, it's great. But in other exchanges on the matter, I was clearly told I couldn't get SFTP for Apache http server.

In the absence of SFTP access, and in order to be able to perform small maintenance tasks (not the full web-app). If answer to SFTP use is definitely NO: then the only thing I could imagine as usable is an identity of the web-app apache http dir, accessible and visible through the i-marine workspace, where we can perform easily CRUD operations interaction with the workspace. Without this and without SFTP access, we will tend to use external apache http servers. Yet the case for PAIM, TunaAtlas, and probably soon the same for AquacultureAtlas.

Hope this clarifies
Cheers

Hi @emmanuel.blondel@fao.org, the automatic deployment on access.d4science is intented to serve what you described as 1)-
1- basic user who wants to test a web-app online, and with no intention to maintain it behind

For users of type 2), we are going to provide a proper solution for hosting.

So, for PAIM, @andrea.dellamico@isti.cnr.it will provide access to a host via SFTP. This is the shortest solution we can provide. Alternatively, the option through the workspace is also possible but it will require some additional time to configure it (we are not yet at the stage where a user can do it in a fully-automatic way).

For the other web apps, Tuna Atlas and Aquaculture Atlas, please open specific tickets.

To be more specific, I'm going to create a new VM where you can upload the app files. The app will be reachable by the same reverse proxy used by the geoserver, so http(s)://paim.d4science.org//.

This is the short term solution. On the long run we should setup a proper virtual hosting environment to host the static web applications.

Thanks @andrea.dellamico@isti.cnr.it , would it possible to have similar for Tuna Atlas? reachable on https(s)://tunaatlas.d4science.org This will allow me to deploy the global Tuna atlas map viewer prototype developed recently, and hopefully to integrate it in the Tuna Atlas VRE. Thanks in advance.

In term of upload privileges for these 2 apps:

• PAIM: @debhasish.bhakta@grida.no + @levi.westerveld@gmail.com + myself
• Tuna Atlas: myself

In addition we may need a similar one for Aquaculture Atlas http(s)://aquacultureatlas.d4science.org for there to deploy the Aquaculture viewer. I invite @nlongepe@cls.fr to clarify his deployment needs.

Thanks a lot Andrea, could you please create a separate workspace available for 'aquacultureatlas' and give me access to me for now. I will then liaise with CLS. Thanks again for this

Done. There's no ssl certificate yet for aquacultureatlas.d4science.org.

Thanks @andrea.dellamico@isti.cnr.it I've tried to connect through PAIM and TunaAtlas without success. I'm using the usual ssh key i've provided to D4science.

Sorry, my bad. When I added the user for aquacultureatlas a ssh configuration was reset to an incorrect value. I just fixed it.

Thanks Andrea, now it works.

@andrea.dellamico@isti.cnr.it i've uploaded the current tuna atlas prototype here: https://tunaatlas.d4science.org/tunaatlas/ see in comparison with https://mdst-macroes.ird.fr/tuna-viewer/ Don't know why but under D4science, font-size is altered. I had the same with access.d4science.org Can it be fixed?

Hm. Where? I don't see any difference on the browse and query output (safari on OSX, I can test other browsers later).

the entire body of the web-page. Working with Chrome here, same happens on Firefox.

Ok....apparently Chrome has other weird stuffs, it seems that on D4science default page zooming was on 90% (??!?). I don't know why this happened. Sounds like smthg in cache similar to the issue of XML request and that is not remove when cleaning cache (which btw i didn't solve it on Chrome).

I don't know how to help you on this. I made another check and the main page looks always identical to me on every browser, with fonts that have the same size of the ones in your https://mdst-macroes.ird.fr/tuna-viewer/ screenshot.

I added @nlongepe@cls.fr 's key.

What is the user login for the sftp to static-web.d4science.org for the Aquaculture Atlas ? aaps ?

Nicolas Longépé wrote:

What is the user login for the sftp to static-web.d4science.org for the Aquaculture Atlas ? aaps ?

The user is aquacultureatlas, as the directory name.