# Presentation: 195614

## RDB-Based Configuration Management - A New Approach

**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 MeV 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 CapFast, 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**

- The only source of knowledge is experience.

## The Top 5 Features That We Don’t Like

**100s of tables in 10s 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
- 	AlarmHandler, Archiver, Snapshots, Orbit Correction, StripTool, ... even unknown future applications
**All these are different views to the same data set**

- 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

- 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 structureQuery 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?