Support #1216
closed
Test StatMan 1.4.4
100%
Description
This ticket will report the results of the tests on the StatMan version that will be release 3.9.
A test plan is in the attachment to this ticket.
Files
Updated by Gianpaolo Coro over 9 years ago
This is the result of the test so far:
- When saving data from the StatMan DataSpace, the Workspace explorer does not block the Save button and does not alert about the saving being in progress. This causes a user to be confused about what is going on and possibly to save one table multiple times.
- The map production algorithms do not work
Point 2 is under investigation. @g.panichi@isti.cnr.it could you please explain point 1?
Updated by Gianpaolo Coro over 9 years ago
- Status changed from New to In Progress
Point 2 could be due to a mismatching in the configuration of the GHN. Probably the start scope should be set to VO instead of root.
Point 1 seems to be a bug.
@roberto.cirillo@isti.cnr.it could you please compare the configuration of the previous installation (under the gcube2 user) or of the production environment with this new installation you did?
Updated by Fabio Sinibaldi over 9 years ago
Investigating the code and the behavior of production environment we found that the current SM implementation uses always the scope of ComputationResource thread to execute computation (only exception, it uses infrastructure scope for D4Science ones).
Point 1 failed because the thread's scope was gcube, and that scope wasn't fully configured for GIS.
Since startScope was already set to devsec in statstical-manager.d.d4science.org, we just restarted the container.
Now the computation succeeds, using devsec scope.
We need to investigate whether the ComputationResource uses only one scope (and how the logic chooses which scope to use) or there are more instances to use (thus we need to add logic to choose accordingly to caller scope).
Updated by Roberto Cirillo over 9 years ago
Gianpaolo Coro wrote:
Point 2 could be due to a mismatching in the configuration of the GHN. Probably the start scope should be set to VO instead of root.
Point 1 seems to be a bug.@roberto.cirillo@isti.cnr.it could you please compare the configuration of the previous installation (under the gcube2 user) or of the production environment with this new installation you did?
The configuration of both ghn and statistical-manager-service seems to be the same configuration done under the gcube2 user. The only difference is the ghn version. Under the gcube user, there is the last ghn version.
By the way I don't understand what means "The map production algorithms don't work" I cannot help you about this
Updated by Giancarlo Panichi over 9 years ago
The problem on interface has been resolved and can be verified in dev, I put in the build the portlet on Etics.
Updated by Fabio Sinibaldi over 9 years ago
The problem with scope handling has been identified,fixed and released. The activity has been reported in #1230
Updated by Gianpaolo Coro over 9 years ago
- % Done changed from 0 to 80
The StatMan 1.4.4 is currently working on the dev environment, although for Point 2 bug we just have a workaround in place, maybe.
@fabio.sinibaldi@isti.cnr.it are you going to release the scope handling bug fix in version 1.4.4 or in next version? Have you already put it on 1.4.4?
In the former case we need to re-execute all the tests also via web interface.
Updated by Fabio Sinibaldi over 9 years ago
As reported in #1230, the fix is already deployed in statistical-manager.d.d4science.org (devsec) and it's been already released with SM 1.4.4 under gcube 3.9.0
Updated by Gianpaolo Coro over 9 years ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
User interface tests were successful.
Just note that the scope set to local algorithms is the VRE scope, whereas the one set to remote algorithms is the Infrastructure scope. This is a well know behaviour of the "old" StatMan which still works in prod. environment, but that will be harmonised in the next StatMan version.
