1 / 8

LSA/ InCA changes during LS1

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

joella
Télécharger la présentation

LSA/ InCA changes during LS1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related