Project Activity #4281

Project WP #629: WP4 - VREs Deployment and Operation [Months: 1-30]

Check the feasibility of user's requirements

Added by Gianpaolo Coro over 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:Jun 21, 2016
Priority:NormalDue date:
Assignee:Gianpaolo Coro% Done:

50%

Sprint:Algorithms Integration
Participants:
Milestones:
Duration:

Description

Julien Barde has risen the following requirements:

1 - Is it possible to have the user name indicated along with the token in the Service Authorization Portlet? (@costantino.perciante@isti.cnr.it and @massimiliano.assante@isti.cnr.it )

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. (@lucio.lelii@isti.cnr.it )

Could you please help me understanding the feasibility of the above requirements?


Related issues

Related to gCube - Feature #4392: Update the Token Generator portlet to show the current us... Closed Jun 23, 2016
Related to gCube - Feature #4600: Update Token Generator portlet to generate a labelled token Closed Sep 07, 2016

History

#1 Updated by Costantino Perciante over 3 years ago

Do you mean the Token Generator portlet? If it is so, yes it can be done without too much effort

#2 Updated by Pasquale Pagano over 3 years ago

as far the second bullet I discussed it with @lucio.lelii@isti.cnr.it. 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.

@costantino.perciante@isti.cnr.it 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, ...

#3 Updated by Gianpaolo Coro over 3 years ago

That's great.

#4 Updated by Costantino Perciante over 3 years ago

  • Related to Feature #4392: Update the Token Generator portlet to show the current user's username information added

#5 Updated by Costantino Perciante over 3 years ago

  • Related to Feature #4600: Update Token Generator portlet to generate a labelled token added

#6 Updated by Pasquale Pagano over 3 years ago

  • Parent task set to #629
  • % Done changed from 0 to 50
  • Status changed from New to In Progress
  • Tracker changed from Support to Project Activity

#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.

#9 Updated by Gianpaolo Coro over 2 years ago

  • Status changed from In Progress to Closed

This is an old ticket and the reported discussion is quite old too and is being accounted for in several tickets.

#10 Updated by Julien Barde over 2 years ago

Ok but could you please provide then the references of the tickets which replace those closed ?

#11 Updated by Lucio Lelii over 2 years ago

They are already linked as related issues and both closed.

#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

Also available in: Atom PDF