FSM configuration

[plasorak]

... are a mess that we'll need to fix, at some point (not for 5.1.0). There's a lot of information repeated and information that isn't used. We'll wait first for the FSM sequence commands to be implemented correctly, and should do another pass here.

[plasorak]

Giovanna had a first proposition, given the following:

<class name="FSMxTransition">
 <attribute name="transition" description="The main transition that this pre/post transition applies to" type="string" is-not-null="yes"/>
 <attribute name="order" type="string" is-multi-value="yes" is-not-null="yes"/>
 <attribute name="mandatory" type="string" is-multi-value="yes"/>
 </class>

We should make order and mandatory relations.

[plasorak]

• We should not have FSMcommands and FSMtransitions in the schema (they are the same, in fact, I believe that FSMcommands are not used).
• FSMtransitions should accept parameters (for example disable_data_writer is done in the user_provided_run_number action in drunc - that's wrong).
• Define the boundary between OKS and RCIF, following the work from the bullet point above: if the FSM is defining that disable_data_writer is a parameter at start, then what is the use for StartParams in RCIF? We could take this the other way around and define start as "needing" to populate the StartParams from RCIF. This needs to be discussed.
• The FSMactions link to FSMcommands is very complicated: they should be decoupled. The FSM is one thing, the actions are just run control configuration. Controllers should have a relationship to an FSM and to actions, so that we don't need to redefine and FSM if we want to alter the actions.
• The schema of the FSMactions is also very complicated. Either we define methods that can be run before or after a certain transition in the configuration, either we let the name of the methods to be bound to the pre or post transitions sequences in the run control (using the method's name). I vote for the former, since this allows to run many times whatever method we coded once to be called at different stages with a change of configuration.
• Finally, there is this issue which touches on the FSM: Rerun FSM command upon failure drunc#280. For this to work, the configure command should be able to be issued from an error state and the schema should hold this information.

[plasorak]

• And a timeout in the FSMTransitions