1. FSM – ConfDB Integration FW WG Meeting 17 th March, 2006 Fernando Varela Rodriguez, IT-CO (with the input from: Clara, Alex, Sascha, Piotr and Francisca) Outline Aim Prototype Open question Discussion

2. 17 March, 2006FW WG Meeting2 Aim Synchronize the contents of the Configuration DB and the PVSS internal caches to ensure the availability of all configuration data for a given running mode  Configuration DB: holds all configuration parameters  FSM: Recipes are applied when a new command is sent Two tools: However:  ConfDB: recipes may contain a large number of devices  FSM: distributed and local intelligence

3. 17 March, 2006FW WG Meeting3 Interface Implementation as DU Vertex HVLVCooling 1234 12341234 CULU DU DU FSM-ConfDB ConfDB

4. 17 March, 2006FW WG Meeting4 Some assumptions  There is one FSMConfDB DU per either LU or CU  The run mode is passed as a command argument to these DU from the parent CU  The FSMConfDB handles the configuration of all other DU in the control domain  Upon the reception of a predefined command (e.g. LOAD, CONFIGURE), the FSMConfDB DU loads all configurations for a given run mode and for all DU in its control domain from the ConfDB  Recipes are associated to FSM transition Naming convention required for recipes!!!

5. DEMO

6. 17 March, 2006FW WG Meeting6 Initialization of the FSM tree Vertex HVLVCooling 123412341234 ConfDB X X  All FSMConfDB DU must be initialized by calling: int fwFSMConfDB_initialize(string sDomain, string sConfigurator);  Disables the FSMConfDB DU if its parent is not a CU and returns  Builds an internal list of DU in the SMI++ domain to be configured  Initializes the connection to the ConfDB  If success, sets the state of the DU to NOT_READY, otherwise ERROR

7. 17 March, 2006FW WG Meeting7 New configuration request Two scenarios:  On-the-fly configuration, e.g. thru CONFIGURE command where this command is also defined for other DU in the tree -Pro: It would not require to define an additional command and a state throughout the FSM hierarchy -Con: Configuration would imply the addition step of loading the recipes  Preloading of recipes, e.g. LOAD command only defined for CU/LU and FSMConfDB DU -Con: Requires the LOAD command and the LOADED state to be implemented by the CUs -Pros: Could load the recipes at any moment, e.g. one could event prepare for COSMICS when a PHYSICS run is about to finish

8. 17 March, 2006FW WG Meeting8 Request for new configuration (2)  FSMConfDB DU gets the run mode: fwDU_getCommandParameter(domain, device, "sMode", mode);  For On-the-fly configuration: The other DU in the domain wait for the FSMConfDB to finish uploading the recipes for the run mode: bool fwFSMConfDB_waitForStateChange(string sDomain, string sConfigurator, time timeout);  FSMConfDB retrieves all recipes for the given mode from the ConfDB int fwFSMConfDB_cacheAllRecipesForMode(string sDomain, string sConfigurator, string sMode = "");  FSMConfDB organizes the PVSS internal caches DOMAIN_NAME/RUN_MODE/FSM_CMD, e.g. EBC/PHYSICS/CONFIGURE

9. 17 March, 2006FW WG Meeting9 Applying recipes If DUs apply recipe: FwAioVertexCooling_doCommand(string domain, string device, string command){ fwFSMConfDB_ApplyRecipeFromCache(domain, device, command); } BUT… Could become very inefficient since the Configuration DB tool is optimized to apply a recipe to a bunch of devices at the same time

10. 17 March, 2006FW WG Meeting10 Applying recipes Who applies the recipes?  The FSMConfDB DUs?  Better performance but…  Does it provide all functionality required?  Each device unit? Total flexibility but how to organize the caches?  One cache per device? => Too many dps being created/deleted  Single cache per domain and recipe? => ConfDB tool could become slow  Several caches per domain => Recipe Dictionary

11. 17 March, 2006FW WG Meeting11 Applying recipes (3) Recipe Dictionary PHYSCIS/ CONFIGURE PHYSICS/ GOTO_STG_1 PHYSICS/ GOTO_STG_2 PHYSICS/ GOTO_READY COSMICS/ CONFIGURE COSMICS/ GOTO_READY device1111 …1111 device10001111 Device1001211212 211212 device2000221213 …22323 deviceNmn2324  It would be set up by the FSMConfDB DU  The other DU would access it to find out the cache to be used

12. 17 March, 2006FW WG Meeting12 Open questions  Is it fine to impose naming convention on recipes?  How to store to the ConfDB the FSM hierarchy  One cache per recipe and control domain or a set of caches? What should the granularity be?  ConfDB intended to be used by means of tag names. How to handle different version? Version name in recipe name?  Who applies the recipe? Generic and fast vs. local and slow?  Applying a recipe must have a timeout?

13. 17 March, 2006FW WG Meeting13 Discussion