90 likes | 233 Views
LSA & InCA in 2014. G.Kruk on behalf of the InCA team. What equipment groups should know about?. Issues from previous years and how do we plan to solve them GM FESA Migration Application Programming Interface (API) changes Deployment plans FESA Property Guidelines.
E N D
LSA & InCAin 2014 G.Kruk on behalf of the InCA team
What equipment groups should know about? • Issues from previous years and how do we plan to solve them • GM FESA Migration • Application Programming Interface (API) changes • Deployment plans • FESA Property Guidelines
Configuration of InCA parameters • Configuration of device property fields to be managed by InCA • Few manual steps requiring usage of 2-3 applications • Tedious and error prone • What devices/properties should be configured? ALL • Test/obsolete devices and test/expert/guru properties managed outside of LSA source of problems • Can’t rely on naming conventions to distinguish OP vs. expert properties • Automate what devices and properties? • “LSA” flag in CCDB on the device and property level configured by the FESA class developer • We’ll pre-configure this flag based on what we have at the moment in InCA • Please set it carefully and don’t abuse it • It’s the public API which should not change
Configuration of Working Sets / Knobs • Configuration of Working Sets and Knobs • Web App in CCDB portal • Flags/Options based on GM concepts from 90’ • Very few people understand it • Configuration in CCDB decoupled from configuration in InCA • Still used by X/Motif and non-InCA accelerators Can’t change it easily • Move the configuration to LSA DB • Edition possible directly from Working Set / Knob “Edit” button • Bring the number of configuration options to minimum, with reasonable defaults • All configurations in one place validation easy to implement • Note: CTF3 (non-InCA) will stay with the current interface
Subscriptions to the hardware • EQP monitoring only partially by the InCA server • InCA server monitors only a subset of all device types • Eqp fragile to the number of clients subscribing e.g. FGC • Calculation of high-level (virtual) parameters • Subscriptions to majority is done directly from Working Sets • Status calculation done on the client side, Slow startup • All communication (SET/GET/MONITOR) will go via InCA server • Keep continuous subscription to device/properties present in working sets and knobs, on all cycles • Faster startup & History of last X values received from HW • Less clients accessing the front-end • Will all the FECs stand the load? • We’ll start testing next week but the full picture we’ll have once all devices are available
GM FESA Migration • Migration Map used to prepare a “Converter” of settings • All settings, including historical ones (+ archives & references) • If GM settings are not valid/important let us know • No need to create converter • We can just erase old devices and settings, and declare them as new
Client APIs • Significantly refactored LSA Application Programming Interface (API) • Concerned developers were informed and some of them started the adaptation • InCA API == JAPC API • Minor change in the code + release • More detailed info for the concerned developers in January
Deployment Plans • We aim for week 5 • Alternatively week 9
FESA Property Guidelines • EDMS Document No. 1335148 • You’ll receive a link to it • Please read it and check if your properties follow these guidelines • It will save all of us from unnecessary problems • Some of the rules will be checked by future versions of FESA