T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management BESSY Configuration Management Plans / Wishes Thomas Birke, Benjamin Franksen, Bernhard Kuner, Ralph Lange, Patrick Laux, Roland Müller, Götz Pfeiffer, Joachim Rahn Experiences with our old system Its deficiencies Lessons learned Requirements for a new system

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management Experiences with our old system Device oriented approach  Set of RDB-tables and at least one application per device class 100s of tables in 10s of different structures  not maintainable (after a few years) Tight coupling of application and RDB is hindering,  several iterations with DB-admin in the beginning Data-maintenance by device-expert is nice – but never really worked Most parameters for most devices are in RDB Cross-application links (ALH, Archiver, Save/Restore…) require central structure or are also unmanageable

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management Information from e.g. capfast-drawings is missing in RDB!  DEVICE:substructure:signal.ATTR for most applications, just the device-name is in the RDB What about version control and fallbacks?  Source-code is in CVS but RDB-contents? The older versions of an application may not even work with the newer RDB-contents!  Use ORACLE features? DBMS_FLASHBACK.ENABLE_AT_TIME(' :00') Experiences with our old system Text Editor Capfast, vdct… DB Template Text Editor SubstitutionsEPICS DB Script RDB

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management More deficiencies No way to map hierarchies  Devices may consist of several sub-devices  A setpoint of a power supply may be the sum of several independent values (higher order inputs) Some devices / device-classes are not in RDB at all  No “need”/time to create appropriate RDB structures Information necessary to configure generic tools (ALH, Archiver…) is wide-spread or not even existing  those tools are configured manually! Set of tables per device-class  uncontrolled growth of RDB  RDB gets more and more unmanageable We found insufficiencies in our naming convention (side-show) DEVICE:substructure:signal.ATTR covereduncovered

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management It’s quite comfortable (in some aspects)  Allows us to use convenient external tools like capfast, vdct, CVS, my-favourite-editor, scripts… to create databases, substitution-files, template-files or other configuration files  Device-oriented approach has some advantages in maintenance E.g. a broken power supply gets replaced by one of a different type  requires change of one entry in RDB Generic tools that access PVs directly (ALH, Archiver, Save/Restore …) are mostly configured by hand Higher level tools (orbit-correction …) access devices via cdev and hence are sufficiently supported (except…)  cdev-classes (for high-level-apps) map directly to device- classes (but also need information from other source!)  But parts of the cdev-ddl file are configured by hand as well Nevertheless, it’s not that bad…

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management What we require a new system to support Generation of *.db, *.substitution, *.template All other kinds of configuration data ALH, Archiver, Save/Restore, Orbit-Correction, other yet unknown applications…  Different views to the same dataset EPICS DB CDEV ddl RDB Save/Restore Archiver AlarmHandlerStripToolgeneric Appl. Screens (adl) Orbit-Corr.Measurement High Level Applications Navigation Displays IOC Preconfigured Applications ** * * Actually configured from RDB **

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management What we require … (contd.) Lose coupling between RDB and Application (ASCII-Files) Experiment with application without changing RDB-contents Develop an application without RDB and then import configuration data CVS-control May cause problems with information that is shared between applications (local copies!) Application generic standard and specialized scripts/programs script/program (may not be necessary) all under CVS control RDB ASCII-Files Capfast, vdct…

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management What else … Continue to use external tools to create configuration data  Capfast, vdct, emacs…  primary source of information may not be in RDB One common generic RDB-structure for all applications  Every type of configuration information goes into this generic RDB structure Application specific frontends for maintenance  web-based, Java, whatever… Scripts to import and export application-specific configuration data  EPICS-DB, Archiver, ALH… Version-Control, Logging  What did who change when (and maybe even why)? CVS of the results gives hints, but may not be enough Application-specific access control  All users/applications use one table!

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management What else … (contd.) Development of a new Application must be possible without requiring the DB-admin or anybody else to create new RDB-structures Generic tools for basic tasks  A simple application should not need to provide fancy SQL-statements or scripts/programs written in whatever language to create its configuration data  Im-/export of standard configuration data db/template/substitution/bpt, ALH, Archiver… Arbitrary hierarchies of name/value pairs with inheritance, overloading, typing, tagging… Object-oriented data model  Classes with inheritance, overloading, types, tags  Complex applications define their own classes  Base functionality stored in base classes Have all existing PVs available in RDB (upfront!) Storage for other user-data (maybe not a must-have…)  part-/serial-numbers, repair/maintenance history…

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management There may be more … … but that’s basically it.

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management What we already did Developed a generic RDB-model  Represents a directed acyclic graph with name/value pairs attached to nodes  4 tables and a few views gadget –nodes in graph gadget_relation –edges in graph gadget_type –arbitrary grouping/tagging attribute –name/value pairs  Access-functions (API) implemented in PL/SQL e.g. access gadgets by path with wildcards /ArchiverConfig/ctl/HF/PAH1R/pCavRdbk /ArchiverConfig/ctl/HF/PAH_R/pCavRdbk /ArchiverConfig/%/pCavRdbk 27 functions/procedures with 60 signatures (~1500 LOC) All write-access and most reads go through API Interfaces with all scripting languages used at BESSY First tests with sample applications  Had to “improve” quality of SQL-statements because of degrading performance

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management DB Structure gadget PKgadget_key name gadget_relation FK1 FK2 FK3 parent child distance type gadget_type FK1 FK2 gadget type gadget_attribute FK1 FK2 gadget name value

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management Gadgets Example A B C1C2 KeyName 1A 2B 3C1 4C2 ParentChildDistance gadget gadget_relation

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management Sample Graph ArchiverConfig ctl HFLifetimePowerSupplies …… … PAH1R …… PAH2R pCavRdbk …… monitor1 period1 write_period30 buffer_reserve3 file_size500 … Application Config-File Group PV-Name

T. Birke  IRMIS Collaboration meeting  March '05  APS  BESSY Configuration Management Sample Graph PAH1RPAH2R pCavRdbk … HOPR650 LOPR0 …… CAN-timeout500 … EPICS-DB RF-System IOC1S15G … …… Application Device-class IOC-name PV-Name CANPORT2 NODEID12 ……