Transcript RDBMS solution for storing and managing Quttor CDB

CMS prototype of an RDBMS
based CDB
Zhechka Toteva
Sofia University/CERN
Why an RDBMS?
•
Preserving the tree structure, we represent it using the relational semantics (foreign
keys etc.)
–
–
•
Using RDBMS we get trivially
–
–
–
•
configuration data processing and comparison
configuration data searching and retrieval
improved processing speed using a minimum procedural logic
A web application was chosen for the user interface
–
–
•
the configuration tree structure of a computer node is consistently described
relational integrity guarantees the creation, deletion and modification of arbitrary part of the
configuration tree
complements the database interface itself
it can be easily made look nicer than command line access
We argue that all above can eliminate the need of a description language (PAN)
Base requirements for the
database design
• Deriving from PAN
–
–
–
–
node configuration tree structure
concept of multi-inheritance on configuration groups
model of reusable groups
extensibility
• Additional requirements
– indexes providing faster search
– provide a clear distinction of objects and their instances (OO
model)
• E.g., an object matches a template and an instance matches a
physical entity
– provide two levels of abstraction
• The database logic
• The application logic
Node configuration tree structure –
the object
• A node presentation
– relations to the same table point to the parent node
– i.e., use a foreign key from parentID to nodeID
• Node type is a
– basic data type for leaf nodes
– NULL for inner nodes
• Validation of node values
– on the server side: easier implementation <-> one
more server request to the database
– on the client side: faster validation <-> impact on user
interface (it is our favored way)
• Reusable tree structures
– inline include
– `equalTo` tracks the parent
• A unique identifier for each node
Node configuration tree structure –
the object (II)
•
Transformation of a PAN template to a Record-set
declaration template
pro_declaration_hardware_type;
define type hardware_type = {
"vendor"
? string
"cpus"
: cpu_type[]
"harddisks"
: harddisk_type{}
"disks"
? hdisk_type
"ram"
: ram_type[]
"cards"
: cards_type
"location"
: string
"serialnumber" ? string
"contract"
? contract_type
"lsfmodel"
? string
};
Node configuration tree structure –
the object (III)
• Reusable groups – inline include
Node configuration tree structure –
the object (III)
• Reusable groups – inline include
Node configuration tree structure –
the object (III)
• Reusable groups – inline include
– delete
•
automatically handled by
foreign key constraint
– update and insert
•
procedure logic
Node Configuration Groups
Initialization – instance
• Vector initialization
– nodeValue is the index number/list name
• Node position in an n-dimensional
array
– Index/IndexName – concatenation of
strings containing all the indices/list names
tracking the relative path to the parent
• Two types of inheritance
– sub-tree initialization with a pre-defined
instance - single inheritance
• `underNode` holds the possible father
• incline include
• `equalTo` tracks the parent
– overriding of instances - multi-inheritance
• calculate each time needed
Node Configuration Groups
Initialization –instance (II)
• Creation of reusable configuration groups
– A group used for initialization - points to the parent
node in a configuration tree (`X`)
• eliminate the risk of setting wrong properties of the group
• the tree under `X` can be initialized from a limited set of predefined groups
• no complex procedure logic for searching - decrease the
time to gather configuration data
– Hierarchies of groups
• reuse groups defining an arbitrary part of the configuration
tree
• reuse groups defining hundreds of software packages
Node Configuration Groups
Initialization – instance (III)
– XML generated for the configuration group where
`isComputerNode`=yes
– Software-packages/groups relation stored in a
different table
• handle the package-version-repository dependencies
automatically
• avoid searching in a long array or a name list
• A reasonable balance between inline include
and tracking the parent
User Interface
• readable and
comprehensive view
of desired information
– visual presentation of
the tree structure
– limit the user choice by
HTML listbox controls
– facilitate basic data
operations
User Interface (II)
– creation/modification wizards
• easier administration of configuration groups etc.
– statistics
• comparison of configurations
– separate the application logic from the data
management logic
• the application is responsible for implementing an
instance from an object
• validate as much as possible outside the database
User Interface (III)
• Things to be done
– management of software groups
• trivial
– configuration comparison
• No major difficulties expected
– user access management
• many implementations to choose from
Summary
•
It is feasible to use a relational DB for the functionality of CDB
– With a reasonable effort
•
Obvious advantages of a web interface compared to a command line
– Nice view of all needed information
– Dynamic presentation of possible choices depending on what is the desired
action
– Flexibility of user management, DB functionality extension