Date: Jun 29 2003; Last revised: Aug 05 2003
In this article, I describe the important changes that are planned for RRFW version 0.1.X.
As noted by many users, RRFW lacks the scalability when the number of network devices is more than 100. The XML compiler takes minutes to process the configuration, and the Collector process initialization time is too long.
Christian Schnidrig <christian.schnidrig@gmx.ch> has proposed a solution to split the database into several subsystems, each being compiled separately, and with separate collector process. In his concept, there is a "global" datasource tree, and "subsystem" trees, each making a subset of global datasource nodes.
I propose to have a number of independent datasource trees, without any superset. This would ease the administrator's work, and add more security.
Instead of @RRFW::Global::xmlFiles, the following hash will contain
the information about the trees:
%RRFW::Global::treeConfig = (
'tree_A' => {
'description' => 'The First Tree',
'xmlfiles' => ['a1.xml', 'a2.xml', 'a3.xml'],
'run' => { 'collector' => 1, 'monitor' => 1 } },
'tree_B' => {
'description' => 'The Second Tree',
'xmlfiles' => ['b1.xml', 'b2.xml'],
'run' => {} }
);
In this hash, the keys give the tree names, xmlfiles points to an array of source XML files, run points to the names of the daemons that would be automatically launched for the tree.
Two additional arrays: @RRFW::Global::xmlAlwaysIncludeFirst and
@RRFW::Global::xmlAlwaysIncludeLast will give a list of source XML
files that are included in every tree, in the beginning or in the end of
the XML files list.
There will be no such thing as globalInstance. All methods and procedures that need to reference the current ConfigTree object will have it as argument.
RRFW::ConfigTree::new() will have a mandatory argument "TreeName".
All datasource trees will share one BerkeleyDB environment. The BDB environment home directory will stay the same, defined by dbhome config variable.
For each tree, the database files will be placed in a separate subdirectory of a subdirectory of dbhome.
All relevant command-line executables will support the following options:
Specifies the datasource tree for processing;
If applicable, performs the operation on all available trees.
When in verbose mode (--verbose), the command-line programs must print the tree names they operate with.
The web interface will take the PATH_INFO string as the tree name. For mod_perl handler, it will be also possible to prohibit PATH_INFO selection, and to configure the tree name in Apache configuration.
When no PATH_INFO is given to the web interface handler, a special superlevel menu may be shown with the list of available trees.
It will also be possible to specify tree-specific renderer attributes, like
%RRFW::Renderer::styling, $RRFW::Renderer::companyName, etc.
Plain CGI interface will not be supported As Renderer gets more complex, CGI initialization time will increase. Also it will become harder to support two user interfaces with similar functionality.
There will be a master process that will launch collector and monitor daemons for each tree. It will be configurable from a separate file, specifying the daemons and execution parameters for each tree.
The master process will watch the child processes and issue warnings in the events of child process termination.
Stopping the master process will stop all child daemons gracefully.
In RRFW version 0.0.X, all the parameters for datasources, views, monitors, and tokensets are stored in configuration.db database.
As proposed by Christian Schnidrig, storing all non-datasource objects information in a separate database would improve the scalability.
In RRFW version 0.1.X, datasource parameters will be stored in ds_config.db, and all other object's parameters in other_config.db.
The XML compiler will have a new option, --nods, which disables processing of <datasources> elements in the input XML files.
In addition to ConfigurationReady flag, there will be a flag that indicates
the readiness of datasource tree only.
All these measures will allow faster administration and testing of non-datasource objects, and will prevent the collector from unneeded interruptions.
User privileges will apply to the tree level: across one datasource tree a given user will have uniform privileges.
Each user belongs to one or more groups. Privileges are assigned to groups only, not to individual users. Groups are one-level deep: they consist of users only. Probably in the future groups will consist of groups too.
In the beginning, only one privilege will be implemented: DisplayTree. The design should be flexible enough to add more privileges in the future. Examples: GenerateReport, Debug, ScheduleTask, and so on.
Privileges maintenance interface will include a command-line utility. In the future, a web interface is also possible. In this case, a new privilege will be added: EditPrivileges.
Privileges editor will include the following functions:
Privileges logics implementation must be separate from the database backend. At first, BerkeleyDB backend will be supported. In the future, LDAP backend is possible.
Copyright (c) 2003 Stanislav Sinyagin ssinyagin@k-open.com