RRFW Requirements Version 0.1

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.


Independent datasource trees

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.

Changes in rrfw-siteconfig.pl

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.

ConfigTree object internals

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".

Database structure

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.

User interface

All relevant command-line executables will support the following options:

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.

Daemons launch master

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.


Separate database for non-datasource objects

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

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.


Author

Copyright (c) 2003 Stanislav Sinyagin ssinyagin@k-open.com