T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management BESSY Configuration Management Plans / Wishes Thomas Birke, Benjamin

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


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


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


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


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…


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

**


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…


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!


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…


There may be more …

… but that’s basically it.


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


DB Structure

gadget

PK gadget_key

name

gadget_relation

FK1FK2

FK3

parentchilddistancetype

gadget_type

FK1FK2

gadgettype

gadget_attribute

FK1FK2

gadgetnamevalue


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


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


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

… …

Documents

T. Birke IRMIS Collaboration meeting March '05 APS BESSY Configuration Management BESSY Configuration Management Plans / Wishes Thomas Birke, Benjamin