Data Staging/DKcontribution

My contribution to the project was:

• Initial development of the scheduler, DTR, DTRList classes. Since all the other have been working with them extensively and know them well no additional explanation is needed.

• Introduction of the transfer share to the scheduler.
  • The class TransferShares is located in scheduler.h and scheduler.cpp files. I tried to comment extensively the purpose of each method in scheduler.h to make the code self-explanatory. Currently transfer shares that correspond to DN, VO-name, VO-group and VO-role are coded. But since TransferShare is identified by name and priority assigned to it, to introduce a new type of transfer share one basically needs only to introduce a method of extracting the name from needed place, that could be output of ARGUS plugin, something in job description, whatever.
  • In Scheduler::main_thread there's an example of how transfer shares are initialized. That of course should be done by the configuration module when A-REX starts. A thing to have in mind when data staging will be connected to real A-REX.
  • The DTRs are sorted according to their priorities, which is (Priority_of_the_share_this_dtr_belongs_to * Priority_specified_in_job_description). So the DTRs with higher priorities will start first, if their transfer share has free slots.
  • Priority_specified_in_job_description is "Priority" parameter from the job description divided by 100. So the user can specify the priority from 1 to 100 percent. 100 percent divided by 100 will results in 1, so the DTR will receiver the maximum priority the equals the priority of the share. 50 / 100 = 0.5, so the DTR will receive half the priority of the share, and so on. The priority is set in scheduler::receive_dtr (request.set_priority).
  • I made XRSL and ARCJSDL parser recognize the priority parameter in job description. It is transferred to JobLocalDescription.Application.priority field and can be extracted from it in. I added the commented lines to DTR constructor that will do the job in the future: now it's not possible, because manually created JobDescription stub doesn't have any local description and it's quite cumbersome to initialize it manually and probably is not worth effort.
  • I haven't updated the documentation yet.