Project Activity #4281
Project WP #629: WP4 - VREs Deployment and Operation [Months: 1-30]
Check the feasibility of user's requirements
|Status:||Closed||Start date:||Jun 21, 2016|
|Assignee:||Gianpaolo Coro||% Done:|
Julien Barde has risen the following requirements:
2 - Is is possible to distinguish the kind of client that is invoking a service via Http? For example, to distinguish a Java client from an R client or from a Browser. (@firstname.lastname@example.org )
Could you please help me understanding the feasibility of the above requirements?
#2 Updated by Pasquale Pagano over 3 years ago
as far the second bullet I discussed it with @email@example.com. The idea is to create a new portlet that allows generating token for a system client. The differences between the two types of token are the following:
- a user token is for human interaction;
- a system token allows to specify also the name of the service using that token: e.g. the token released to fishbase would report that it was requested by gianpaolo.coro for an application called fishbase. This information will be maintained by the Authorization service and returned when needed.
@firstname.lastname@example.org will have to implement a new portlet to require it. In general a user may request several tokens, one for each application client that needs to call infrastructure services. Thus GP could require one token for QGIS, another one for fishabase, ...
#7 Updated by Julien Barde over 3 years ago
Some additional feedback:
* When removing experiments: it would be easier if we could select multiple experiments once in the "Check the computations" item (using for example check boxes or Shift select...) to avoid a selection one by one,
* some experiments are run in the context of another experiment: we loose this information in the "Check the computations" item. For example, I have been running 88 simulations of Ichthyop through WPS Exceute Process Queries (using this algorithm identifier ICHTHYOP_MODEL_ONE_BY_ONE) sent by a single experiment (using this algorithm identifier ICHTHYOP_MODEL_MULTIPLE_RUNS). It would make sens to know that these 88 iterations of ICHTHYOP_MODEL_ONE_BY_ONE algorithm executions have been submitted within the context of another one (managing dependencies). For now they appear at the same level but there are links / dependencies between them. This makes browsing of results complicated. Could we have a tree view for example ?
#8 Updated by Julien Barde over 3 years ago
Regarding SAI, it's very difficult for a user to understand why some I/O are automated the first time we set up the main code and why it's not automated anymore once we modify it thereafter. It would be great if every time we save the main code it could be automated accordingly in the I/O, including the list of packages. If not, most of people won't understand why it fails I think.
Moreover, if my understanding is correct, you are using 52°North WPS server. There is an interesting information with 52°North WPS server in the describeProcess query (eg http://mdst-macroes.ird.fr:8084/wps/WebProcessingService?Request=DescribeProcess&Service=WPS&version=1.0.0&identifier=org.n52.wps.server.r.Atlas_i1_SpeciesByOcean) where you can see the code source. It can be useful to check what is the underlying code which is really executed. It would enable us to know it our modifications in SAI are really taken into account.
#12 Updated by Gianpaolo Coro over 2 years ago
Here is a summary of them:
1 - avoiding issues of non-updated code running on DataMiner (related to this ticket) #9328
2 - over-simplify the import of R scripts and other processes #8819
3 - pass user's VRE token (and other e-Infra information) to R scripts #8952
4 - add metadata and source code to the process #5559
5 - enhance netcdf and other data transferring #5549
6 - increasing the computational resources for VREs #9321