D4Science Infrastructure

It is still unclear to me why we need to create new instances and not to share the existing ones to this environment. Could you please clarify? thanks.

DMPoolManager currently runs only on one scope at a time accepting a configuration that defines both its Stage and Production environments. The configuration also contains the definition of the reference ghost machines (DataMiner) for both environments, as well as the folder name on svn where to store the jars and the algorithm deployment information. Using the environments folder defined on svn the DMScheduler aligns the various DataMiners. Currently, if you want to have a TextCrowd environment, you need to create a new one to maintain it separated from RPrototypingLab. Even assuming that in the future DMPoolManager can run on more than one scope at a time, some issues still remain. For example, the ghost publishes on the IS in a specific scope, creates the algorithm jars, and register some information about the algorithm such as the generation string, the last request and so on... all this information and files are subsequently saved on our svn repository becoming key for keeping the alignment on svn for that specific environment. For this reason, if a ghost publishes in multiple environments, there could be issues with different algorithms versions creating conflicts over svn for the same algorithm.This is, of course, not the best solution, it would be better to have a db where to store all the information including the files and metadata that we could add to the algorithm. This can be addressed in some future activities.

I've added the Dataminer service endpoint resource. Now, it's needed to share the ghost instance and the dm-pool-manager instance from RPrototypingLab environment.

I've changed the DMScheduler settings of dm-192-168-100-104.garr.d4science.org (dataminer instance deployed on TextCrowd VRE), in order to pull the algorithms from svn proto path and not from svn production path.