Transcript RDB-Based Configuration Management

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
Text Editor
DB Template
CapFast, vdct …
EPICS DB
Script
RDB
Substitutions
Text Editor
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
IOC
EPICS DB
CDEV ddl
High
*
*
Measurement
Orbit-Corr.
RDB
Screens (adl)
Archiver
* Level
Applications
*
*Navigation
Displays
AlarmHandler
generic Appl.
Save/Restore
StripTool
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
IOC1S15G
…
CANPORT
2
NODEID
12
…
…
PAH1R
pCavRdbk
PAH2R
…
…
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?