bessy configuration management plans / wishes
DESCRIPTION
BESSY Configuration Management Plans / 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. - PowerPoint PPT PresentationTRANSCRIPT
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
Information from e.g. capfast-drawings is missing in RDB! DEVICE:substructure:signal.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_TIME('2005-02-28 10:00')
Experiences with our old system
Text Editor
Capfast, vdct…
DB Template
Text EditorSubstitutions
EPICS DB
Script RDB
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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)
DEVICE:substructure:signal.ATTR
covered uncovered
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
It’s 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
Nevertheless, it’s not that bad…
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
What we require a new system to support
Generation of *.db, *.substitution, *.template All other kinds of configuration data
ALH, Archiver, Save/Restore, Orbit-Correction,other yet unknown applications…
Different views to the same dataset
EPICS DB
CDEV ddl RDB
Save/Restore
Archiver
AlarmHandler
StripTool
generic Appl.
Screens (adl)
Orbit-Corr.
Measurement
HighLevelApplications
NavigationDisplays
IOC
Preconfigured Applications
**
*
* Actually configured from RDB
**
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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!)
Application
generic standardand specialized scripts/programs
script/program(may not be necessary)
all under CVS controlall under CVS control
RDB ASCII-Files
Capfast, vdct…
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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!
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
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…
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
There may be more …
… but that’s basically it.
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
What we already did
Developed a generic RDB-model Represents a directed acyclic graph
with 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/ArchiverConfig/ctl/HF/PAH_R/pCavRdbk/ArchiverConfig/%%/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
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
DB Structure
gadget
PK gadget_key
name
gadget_relation
FK1FK2
FK3
parentchilddistancetype
gadget_type
FK1FK2
gadgettype
gadget_attribute
FK1FK2
gadgetnamevalue
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
Gadgets Example
A
B
C1 C2
Key Name
1 A
2 B
3 C1
4 C2
Parent Child Distance
1 2 1
2 3 1
1 3 2
2 4 1
1 4 2
gadget
gadget_relation
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
Sample Graph
ArchiverConfig
ctl
HFLifetime PowerSupplies… …
…
PAH1R… …PAH2R
pCavRdbk… …
monitor 1
period 1
write_period 30
buffer_reserve 3
file_size 500
…
ApplicationApplicationConfig-FileConfig-FileGroupGroupPV-NamePV-Name
T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management
Sample Graph
PAH1R PAH2R
pCavRdbk …
HOPR 650
LOPR 0
… …
CAN-timeout 500
…
EPICS-DB
RF-System
IOC1S15G
…
… …
ApplicationApplicationDevice-classDevice-classIOC-nameIOC-namePV-NamePV-Name
CANPORT 2
NODEID 12
… …