LSA/InCA changes during LS1

LSA/InCA state during LS1 Keep the existing released versions of all LSA/InCA modules We frozen these versions in a dedicated SVN branches The PRO database won’t be changed and all LSA/InCA servers will be up and running Until the moment when we complete all the modifications We’ll not release anything as PRO except blocking fixes for LN4 or CTF

LSA DB schema change Why What Impact Automate synchronization between CCDB and LSA DB Improve lifecycle management of devices and parameters in LSA DB Add support for missing setting types i.e. enum arrays What Change of LSA DB schema First NEXT and TEST DB, later PRO DB Impact No need to change the code Some attributes will be added to certain domain objects Code from SVN Trunk won’t work with PRO DB Released PRO code won’t work with NEXT DB

Repackaging of LSA modules Why Currently 18 modules 8 are necessary on the client side  compatibility issue between them Not easy to setup and maintain the development environment in Eclipse Especially for people from outside of the LSA team who contribute to the code What Client side  lsa-client, lsa-domain, lsa-domain-cern Server side  lsa-core, lsa-core-cern Impact - all apps depending on LSA Remove dependency on the old packages from product.xml Keep dependency only on lsa-client Re-release to use the new products

LSA Client APIs cleanup Why The LSA API is huge and was growing over the last 10 years There are a lot of deprecated and obsolete methods Some of them were deprecated long time ago but are still in use For a few different reasons Some Domain Objects are not in the most logical java packages Some methods are not in the most intuitive Client Controllers What Remove unused methods Move some Domain Objects to different Java packages Move some methods between Client Controllers Deprecate methods that we want to suppress  in the first step Remove deprecated methods  in the second step Impact The existing functionality won’t be removed but you might need to update your code to: Fix the import of domain objects Use the same method but from another Client Controller Use another method

Suppress Context User Group concept Why Concept introduced about 7 years ago to have a dedicated set of cycles meant for “Expert Settings” But finally it was used only partially in SPS Complicates unnecessarily the API What The Context User Group selection will disappear from GUIs The corresponding methods will be deprecated in the first step and removed in the second step e.g. findCycles(String accelerator, String usergroup) Impact Applications have to adapt to not use the deprecated methods The client code will simplify

Move Working Sets and Knobs configuration from CCDB to LSA DB Why The content of WS and Knobs is driven by LSA parameters But the GUI layout and several attributes are in CCDB Some of them are obsolete Some of them are duplicates of what we already have in LSA DB LSA DB is more natural place to keep also this config  one place to configure everything What The Working Set content (devices) and meta-properties will be moved to LSA DB japc-ext-dirservice APIs will be adapted to fetch data from LSA DB rather than from CCDB Impact Any application which uses directly CCDB API or SQL to fetch info about WS and Knobs  adapt to use InCA APIs

Release plan Release the modifications in Q3 2013 as NEXT For early adopters who want to test it using LSA NEXT database Release the modifications as PRO in Q4 2013 At the same time update PRO database schema and redeploy all LSA and InCA servers We’ll also provide a documentation (JavaDoc + Wiki) describing the changes From this moment on – all applications can follow and adapt Release again as PRO in March 2014 Deprecated methods will be removed