150 likes | 288 Views
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.
E N D
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 • Mostparameters for most devices are in RDB • Cross-application links (ALH, Archiver, Save/Restore…) require central structure or are also unmanageable
Text Editor DB Template Capfast, vdct… EPICS DB Script Substitutions Text Editor Experiences with our old system • 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') 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
Nevertheless, it’s not that bad… • 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 ofthe cdev-ddl file are configured by hand as well
HighLevelApplications IOC EPICS DB Measurement CDEV ddl Orbit-Corr. Actually configured from RDB NavigationDisplays Screens (adl) Archiver AlarmHandler generic Appl. Save/Restore StripTool Preconfigured Applications 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 * *
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
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 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/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
Gadgets Example gadget A B gadget_relation C1 C2
Sample Graph ArchiverConfig ApplicationConfig-FileGroupPV-Name … ctl … … Lifetime HF PowerSupplies … … PAH1R PAH2R … … pCavRdbk
Sample Graph EPICS-DB ApplicationDevice-classIOC-namePV-Name … RF-System IOC1S15G … … PAH1R PAH2R … pCavRdbk