Attribute based primary view

Proposal

Netcool eventviewer views, especially the primary view, based on special event attributes

Goal:

• To keep view definitions constants…
• While allowing flexiblity in controlling all views

Reasons:

• View definitions are everywhere:
  • Desktop eventviewer uses local config files
  • Operator portal uses separate config file
  • Operator alert notification tools use local config files
  • Webtop uses its own config file
• Temporary exclusions will become more frequent
• Customer based permanent exceptions to the base view definition will happen

Proposed Solution:

• Use special attributes on the events in Netcool that control inclusion in views
• All view definitions will be based on these attributes
• Controlling views is then accomplished by controlling the values of the attributes, whereas the definitions don’t have to change

Details

View Attributes that control the primary view

• Keep a number of attributes (logically) that are stacked in 4 levels. Attributes at higher levels override those at lower levels.
• Attributes come in two varieties: those that control inclusion in the primary view, and those that control exclusion.
• The proposed levels are
  1. Level 1 – base definition.Inclusion only.Mechanism:

     Will define something similar to the current base without the Viewflag provision. This can be set using an automation

  2. Level 2 – permanent exceptions2a. Exclusions2b. Inclusions

     Purpose:

     Special configurations for customers or core devices

     Mechanism:

     Needs access to customer information and it should be possible to add per customer configurations in a scalable way. Best if these are configurable from operator portal. Needs mechanism that has access to external datasources (outside netcool). That limits us to either impact or data server

  3. Level 3 – temporary exceptions3a. Exclusions3b. Inclusions

     Purpose:

     Cope with construction and change work

     Mechanism:

     See level 2

  4. Level 4 – manual override4a. Exclusions4b. Inclusions

     4c. Pending

     Mechanism:

     Per event direct set of attributes. Right-click tool in event view, script in Op portal. Like current “move to pending”, “move to primary”, “force move to primary”

  Primary view definition:

  
"Level4Incl or (not Level4Excl and (Level3Incl or (not Level3Excl and (Level2Incl or (not Level2excl or Level1Incl))))"
That means: Includes on the same level have higher priority then excludes.

  As for implementation, this means there are, logically, 8 attributes are needed, but this can be implemented in a variety of ways. Depending on whether we want to optimize clarity or space, we can use something like a bit array in a single physical field, or separate fields for

  each attribute.

  An added benefit of this kind of primary view definition is that it is immediately obvious form looking at the view attributes why an event is in the primary view or not.

  Also derived (non-primary) views can be created based on these views.

Advertisements

Opsware Sync tool update

I updated the Opsware sync tool and checked it into Cycle 12. It will be deployed before cycle 12, however, to get the new servers into Smart24.

It has the following changes:

1. Checks a configurable custom attribute (currently configured to be “VisibleInCP”. If that field has a value of “False” (not case sensitive) then the customer fields are not updated. This prevents servers that were wrongly attributed to a customer in Opsware from showing up under that customer in the Customer Portal
2. Loads Siebel server list once, instead of a separate lookup for each server in Opsware
3. Does not update the Smart24 database unless required (used to always update, even if not necessary)
4. Is read-only by default now. Writing to db requires explicit -W switch
5. Improves logging. By running in read-only mode, the changes that it will make can be assessed and checked before they are actually made
6. Sets the Description field to an empty string for new components to avoid NULL showing up in customer portal
7. Some refactoring of the code

Cycle 12 branch created

I created the cycle 12 branch. The branch name is:

1-7-0-branch

All cycle 12 stuff should go there.

Things that should go on both the branch and the head, can be developed on the branch. Then check out the head and merge the branch onto the head using cvs update -j 1-7-0-branch in the subdirectory of your project.

worklog fixed?

I re-imported the data. If you can see this than it worked.