CURRENT MEETING REPORT

Reported by Rick Strum, Enterprise Management Institute, Inc.

Minutes of the Application MIB Working Group (applmib)

Information was presented about the structure of the sysAppl MIB. Slides illustrating this information are available in a file (applmib/structure.ppt) via ftp. (The slides are in postscript format).

The working group will produce two MIBs, the first being sysAppl MIB (which is currently being worked on by the group), the other being Appl MIB.

• sysAppl MIB

There will be one instance of sysAppl MIB per system sysAppl MIB will require no application instrumentation.

• Appl MIB

The Appl MIB will extend the data model of the sysappl MIB

These will support capturing information about the individual applications based upon data provided by the managed applications.

The work on Appl MIB will follow the work on sysAppl MIB.

In addition to the sysAppl MIB and the Appl MIB, there may be enterprise MIBs created that are specific to particular applications. The result will be a hierarchical relationship of MIBs, working from more generic to more specific. In this structure, the more specific are expected to reference to the more general MIBs rather than the other way around. Examples of more specific MIBs that should reference back to the sysAppl MIB include: HR MIB, madman MIB (network services MIB), HTTP MIB. It was noted that the working group feels that the madman MIB is just another case of a MIB for a specific type of application.

Host Resources MIB

Questions were again raised regarding the differences between the sysAppl MIB and the host resources MIB. It was explained that part of the difference lies in the fact that sysAppl MIB attempts to maintain persistence of information about software, while the HR MIB does not. Also, sysAppl MIB tries to capture the relationship between the various components of an application.

It was decided that the architecture description contained in the beginning of sysAppl will be removed. That information will be enhanced and placed into an informational RFC. The informational RFC will describe how the various pieces of sysAppl MIB and other application-oriented MIBS relate to each other. Weinstock and Saperia will do this work.

George Best will work with Carl Kalbfleisch to create a set of specific usage scenarios for management of Web software. They will then identify which existing objects in sysAppl MIB, and elsewhere, might be used for that purpose; what objects are missing that might be provided through the addition to sysAppl MIB; and, what additional requirements there are for objects for Web management that would be best met through a MIB for HTTP. The list of additional required objects will include the distinction between information that can be captured external to the application and information that can only be acquired internal to the application (i.e., requiring instrumentation.) Another output of this activity will be a list of proposed items for the Appl MIB. These will be the items that are necessary for the management of any application. Addressing the requirements of web software will serve to point the general requirements and is not intended to produce results that are solely limited to the case of web software. Through this effort, it is expected that the working grouup will get a good start on the work required for the Appl MIB.

Detailed Discussion

It was decided that:

• The primary executable object will be deleted from the sysApplInstalledTable.
  
• A read/write column will be added to the element table (sysApplcfgElmtTable). It will be enumerated integer whose values have yet to be assigned. The use of enumerated value will allow different characterizations to be inferred from the presence of the application. Bob Stewart will propose a name and values for this column.
  
• The sysApplRunTable and sysApplElmtRun Table will each be split into two separate tables. A table will be created for running applications and another for "dead" (pastRun) applications (i.e., a list of applications that have run, regardless of whether they complete successfully or not). Persistence of this information across reboots will be optional.
  
• sysApplRunTable and sysApplElemLimits will be changed to read/write.
  
• The sysApplElemRunTable and sysApplElmtRun Table will each be split into running and pastRun. This will require revisions to the objects. These revisions will be done by Jon Weinstock and posted to the mailing list.
  
• Two additional scalars will be added to the section which contains scalars in the run group. Those scalars will be: agent sample interval, specified in seconds entry lifetime, specified in seconds.
  
• runCpu has been changed to time ticks.
  
• sysApplInstalled index will be changed.
  
• A counter will be added to capture the number of entries that are rolled off of each of the past run table within a period of time because of the size limitation for the table.
  
• sysApplElemRunPath will be changed to sysApplElemRunName.
  
• Under applElemRun there is a need to capture the identity of the user of the application. This will also be carried into the past run table. Default is null. Also contact information and identity of the person who installed the application will also be captured.