1. LSA/InCA changes during LS1

2. LSA/InCAstate 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

3. LSA DB schema change • Why • 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

4. 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

5. 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

6. 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

7. 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

8. 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 InCAservers • 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