Versions Compared

Old Version 2

changes.mady.by.user Sanjay Tripathi

Saved on

compared with

New Version 3

changes.mady.by.user Sanjay Tripathi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This feature will provide the functionality to delete or archive the acknowledged Alerts/Events. In this way admin can get more controls over the Alerts and Events and manage them to get required and useful information. CloudStack admin can manage them by using the APIs or through CloudStack UI. This is a functional specification of feature "Ability to delete/archive Events and Alerts" which has Jira ID CSCLOUDSTACK-___

References

...

Use Cases

  • Root-Admin selects one or multiple Alerts and acknowledge/remove/archive them.
  • Root-Admin selects one or multiple Events and acknowdge/remove/archive them.
  • Domain-Admin selects one or multiple Events and acknowledge/remove/archive them.
  • Normal User selects one or multiple Events and acknowledge/remove/archive them.

References

Feature Specifications

  • Requirements
    • Able to select one or more alerts/events and delete them using API or UI
    • Able to archive the selected alerts/events instead of delete – archive will not show them on the UI/listed via API, but will still be maintained in the DB (for auditing/compliance purposes)
    • Ability to delete alerts by a time period
    • Ability to delete alerts by a “category”?
    • Introduce “alert.purge.delay” – alerts older than specified number of days will be purged. Value set to 0 to never purge events automatically (there already exists an “event purge delay” global config
  • Non-requirements
    • List archived alerts/events via UI/API
  • Configuration
    • There are one global configuration parameters:
      • alert.purge.delay - alerts older than specified number of days will be purged. Value set to 0 to never purge alerts automatically
  • User permission
    • Root-Admin would have privilege to delete or archive the acknowledged Alerts.
    • Root-Admin, Domain-Admin, Normal User would have privilege to delete or archive their respective Events. 

Use Cases

  • Root-Admin selects one or multiple Alerts and acknowledge/remove/archive them.
  • Root-Admin selects one or multiple Events and acknowdge/remove/archive them.
  • Domain-Admin selects one or multiple Events and acknowledge/remove/archive them.
  • Normal User selects one or multiple Events and acknowledge/remove/archive them.

Architecture and Design description

Delete or Archive Alerts

DB schema changes:

Existing schema changes

...

ApiName

Request parameters

Response parameters

Available to regular user

deleteAlert

  • id(can pass one or more IDs seperated by comma)
  • type
  • true/false

No

archiveAlert

  • id(can pass one or more IDs seperated by comma)
  • type
  • true/false

No

In the above mentioned APIs, id and type are optional parameters. If admin can pass one or multiple ids of alert to delete/archive them as per the requirement or if admin wants to delete/archive all the alerts of a particular type then he needs to pass only type parameter along with type value. If admin passes both ids and type then CloudStack will match the ids and type and delete/archive only those alerts which satisfy this criteria.

New classes for client APIs

  •  
  • DeleteAlertCmd.java
  • ArchiveAlertCmd.java

Changes to Existing Files:

  •  
  • Add new methods in *AlertManagerImpl.java *to delete and archive alerts.
  • Add new components in AlertManager.

Delete or Archive Events

DB schema changes:

...