RDBBased Configuration Management A New Approach

1
RDB-Based Configuration Management - A New
Approach
Ralph Lange EPICS Collaboration Meeting at
SLAC, April 2005
2
RDB-Based Configuration Management Reinventing
the Wheel?

• A New Attempt to Make Life Easier
• Forced by the progress on BESSYs
  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?
3
RDB Use for BESSYs 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

4
The Top 5 Features That We Dont 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, theres only one device
  entry in the database

5
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

6
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

7
Sample Graph
8
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 wont work

9
To Sum It Up

• Driving forceThe need to create applications
  more efficiently
• Generic RDB structure to represent
  hierarchiesThe 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 yearWell keep you
  posted on the experiences