BESSY Configuration Management Plans / Wishes

1
BESSY Configuration ManagementPlans / 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

2
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

3
Experiences with our old system

• Information from e.g. capfast-drawings is missing
  in RDB!
• DEVICEsubstructuresignal.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_TIM
  E('2005-02-28 1000')

RDB
4
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) DEVICEsubstructures
  ignal.ATTR

covered
uncovered
5
Nevertheless, its not that bad

• Its 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

6
What we require a new system to support

• Generation of
• .db, .substitution, .template
• All other kinds of configuration dataALH,
  Archiver, Save/Restore, Orbit-Correction,other
  yet unknown applications
• Different views to the same dataset

RDB


7
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!)

Capfast, vdct
RDB
Application
ASCII-Files
generic standardand specialized scripts/programs
script/program(may not be necessary)
all under CVS control
8
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!

9
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

10
There may be more

• but thats basically it.

11
What we already did

• Developed a generic RDB-model
• Represents a directed acyclic graphwith
  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/A
  rchiverConfig/ctl/HF/PAH_R/pCavRdbk/ArchiverConfi
  g//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

12
DB Structure
gadget_relation gadget_relation
FK1FK2FK3 parentchilddistancetype
gadget gadget
PK gadget_key
name
gadget_type gadget_type
FK1FK2 gadgettype
gadget_attribute gadget_attribute
FK1FK2 gadgetnamevalue
13
Gadgets Example
gadget
Key Name
1 A
2 B
3 C1
4 C2
A
B
gadget_relation
Parent Child Distance
1 2 1
2 3 1
1 3 2
2 4 1
1 4 2
C1
C2
14
Sample Graph
ArchiverConfig
write_period 30
buffer_reserve 3
file_size 500

ApplicationConfig-FileGroupPV-Name

ctl


HF
Lifetime
PowerSupplies


PAH1R
PAH2R


pCavRdbk
monitor 1
period 1
15
Sample Graph
EPICS-DB
ApplicationDevice-classIOC-namePV-Name
CAN-timeout 500


RF-System
IOC1S15G


PAH1R
PAH2R
CANPORT 2
NODEID 12


pCavRdbk
HOPR 650
LOPR 0