RDBBased Configuration Management A New Approach Ralph Lange

RDB-Based Configuration Management - A New Approach Ralph Lange – EPICS Collaboration Meeting at SLAC, April 2005

RDB-Based Configuration Management – Reinventing the Wheel? A New Attempt to Make Life Easier Forced by the progress on BESSY’s Willy-Wien-Laboratory project (compact 200 -600 Me. V synchrotron for the German bureau of standards currently under construction at the BESSY site) Discussed and developed by Thomas Birke, Benjamin Franksen, Bernhard Kuner, Ralph Lange, Patrick Laux, Roland Müller, Götz Pfeiffer, Joachim Rahn A question that sometimes drives me hazy: am I or are the others crazy?

RDB Use for BESSY‘s Current Control System Device oriented approach: One set of RDB tables and at least one application per device class Devices are represented by a set of DB templates: Simple templates are edited as plain text, complex templates are managed by Cap. Fast, vdct Substitution files are generated from RDB data by a script in the application directory: Many applications use simple generic scripts, some contain many exceptions Other applications (ALH, Archiver, Snapshots, …) are configured manually in most cases Text Editor DB Template Cap. Fast, vdct … EPICS DB Script RDB Substitutions Text Editor The only source of knowledge is experience.

The Top 5 Features That We Don’t Like 100 s of tables in 10 s of different structures Not maintainable after a few years Tight coupling of application and RDB Several iterations with RDB manager (requiring a few days) when starting a new application Data maintenance by device experts is nice But never worked Most parameters for most devices are in the RDB For some singular devices creating the RDB structures would be just too much effort We never had a complete view of our system Links to other applications (ALH, Archiver, Snapshots, …) are not within the RDB Wildly growing, distributed and unmanageable All internal information from complex template files is missing For complex templates, there’s only one device entry in the database No way to map hierarchies Devices may consist of sub-devices A set point may be the sum of independent values (higher order inputs) Our naming convention is not sufficiently covering the sub-device part A person who never made a mistake never tried anything new.

What We Would Expect From a New System Generation of configurations for all kinds of applications. substitution, . template, . db Alarm. Handler, Archiver, Snapshots, Orbit Correction, Strip. Tool, … even unknown future applications All these are different views to the same data set IOC EPICS DB CDEV ddl High * * Measurement RDB Orbit-Corr. Screens (adl) Archiver * Level Applications * *Navigation Displays Alarm. Handler generic Appl. Save/Restore Strip. Tool Preconfigured Applications * Actually configured from RDB Imagination is more important than knowledge.

A New Attempt Generic RDB model Stores hierarchies allowing “is part of” and “is of type” relationships Represented by directed acyclic graphs with name/value pairs attached to any of the nodes Implemented in 4 tables and a few views RDB structures have no installation and application dependencies Access functions (API) in PL/SQL to be run on the RDB server side 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 Values may contain math and string expressions referencing other names Generic tools to handle the graphs and name/value pairs Graphical application to manipulate the graphs Insanity: doing the same thing over and over again and expecting different results.

Sample Graph Application Device Class IOC Name … PV Name EPICS-DB CAN-timeout 500 … RF-System IOC 1 S 15 G … CANPORT 2 NODEID 12 … … PAH 1 R p. Cav. Rdbk PAH 2 R … … HOPR 650 LOPR 0 … … I used to go away for weeks in a state of confusion.

How Far We Got Database Structures finished Basic PL/SQL Functions implemented, stable, being tested Generic Graphical Tool under development Sample Application Test environment is EPICS DB generation – so this works Waiting for the first real world application (this summer) – that naturally won’t work A man should look for what is, and not for what he thinks should be.

To Sum It Up Driving force: The need to create applications more efficiently Generic RDB structure to represent hierarchies: The hierarchy information, which used to be contained in the specific database structure, is now moved to being data in a generic structure Query results are sets of name/value pairs (allowing redefinition and expressions along the hierarchy) Implementation is well under way Tests show promising results, first real applications later this year: We’ll keep you posted on the experiences… If we knew what it was we were doing, it would not be called research, would it?