AlarmNotifier Attaching to wrong landscape

[karen_brooks]

All,

 

I've set up a QA environment and after I start the notifier process, I see that it is attached to the wrong landscape (DSS).  

 

There is no AlarmNotifier running on that server.

 

I deleted the model and cycled the AlarmNotifier process and it comes back with the wrong landscape.  I have not cycled the SS yet, but will soon.

 

Any ideas on how to fix if an SS restart doesn't work?

 

Note:  We did a model gateway export/import to this environment, but no SANM related data was exported by default.

[ackjo04]

Karen,

 

Check out the LANDSCAPE parameter in the .alarmrc file the AlarmNotifier is configured to use. 

The following is from the $SPECROOT/Notifier/README file:

 

LANDSCAPE - landscape where AlarmNotifier will create a DefaultPolicy if a policy is not associated with the AlarmNotifier's application model.

 

Joe

[karen_brooks]

Joe - I added the lh handle of the proper landscape and cycled the services, but it didn't help.

[ackjo04]

Set both the LANDSCAPE and POLICY_LANDSCAPE to the same lh value.

 

Delete the current AlarmNotifier application model

 

Restart AlarmNotifier

 

Joe

[karen_brooks]

Weird stuff, Joe...  The models appear on the DSS and not the MLS.  I deleted them (we have 2) from the CLI on the DSS and validated they were not available in the console at all.

 

I cycled the notifier process on the MLS and they appear again with the wrong landscape.  I may need to open a support case on it.

 

I do see the models on the MLS in the CLl.  Perhaps I'll delete these and bring the DSS down, cycle the processes and see if they associate properly.

[karen_brooks]

Rebooted the servers and saw instances from both landscapes which is better.  Deleted the instances from the DSS.  They may come back if the SpectroSERVER is restarted.