Plans for JEDI-α

Note posted in June 2013: since this post was originated and updated, the activity which it describes led to a successful commissioning of JEDI-α. Work is still under way to tune the database schemas and to complete functional testing.


This is a schematic description of flow of logic JEDI-α and how it compares to Vanilla ProdSys I:

Sequence:
 

Vanilla	[1] "Task Definition"	AKTR tables	[2] ProdSys tables	[3] ProdSys1 sequence
α	-	-	[2'] DEfT tables	[3'] JEDI sequence

Description:

• [1] In the Task Definition object a flag will be added, to differentiate ProdSys1/ProdSys2. If the flag is set to "ProdSys2" then DEfT tables will be filled by the system
• [2'] Tables (as defined in https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkFlow) will be filled by Dmitry
• [3'] JEDI-alpha will take info from the above DEfT tables

Upon implementation, we will be able to debug ProdSys II w/o disturbing the current system and even run production with both systems if needed.

Please comment.

Question: who will register the output dataset(s) in [2']?
In principle it will be transparent for current datasets/containers registration.

Probably ProdSys2 tasks can have a special state and in this case it will be easily seen in monitoring.

Comment from MP: this could be a "type" or "origin" column in the task. Different "state" can make things more complex.