Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Table of Contents
indent20px
styledisc

Introduction

Purpose

In CloudStack, we have features like Alerts and Events that helps administrator in managing the cloud. Admin can get a list of Alerts and Events but there is no way to control them i.e delete or archive them.

This feature will provide the functionality to delete or archive the 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 CLOUDSTACK-874

References

Use Cases

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

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 

...

  • Upgrade scenario
    • CS creates a new column archived of Boolean type in alert and event tables and fill the column with default value 0 i.e. false.

Architecture and Design description

Delete or Archive Alerts

DB schema changes:

...

  • Add archived field to alert table

New client APIs

ApiName

Request parameters

Response parameters

Available to regular user

deleteAlerts

  • ids           (can pass one or more IDs separated by comma)
  • type         (string alert types)
  • startdate  (yyyy-mm-dd)
  • enddate olderthan   (yyyy-mm-dd)
  • true/false

No

archiveAlerts

  • ids(can pass one or more IDs separated by comma)
  • type
  • startdate  (yyyy-mm-dd)
  • enddate   olderthan (yyyy-mm-dd)
  • true/false

No

In the above mentioned APIs, id, type, startdate and olderthan enddate are optional parameters but while calling the APIs atleast one of them APIs atleast id, type, enddate is required. Admin If user pass startdate, then enddate need to be passed i.e enddate becomes required parameter if user passes startdate parameter.  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 category then admin needs to pass only type parameter along with type value. If admin wants to delete/archive alerts older then between some time period then admin needs to pass olderthan parameterboth startdate and enddate parameter, if admin wants to delete alerts older then some time then only enddate required to pass along with the API. If admin passes any combination of parameters (two or all three) then CloudStack will fetch the alerts from database depends on the parameters and delete/archive only those alerts which satisfy this criteria.

Demo Alerts API calls:

New classes for client APIs

...

  • Add archived field to event table

New client APIs

ApiName

Request parameters

Response parameters

Available to regular user

deleteEvents

  •  ids           (can pass one or more IDs seperated by comma)
  • type          (string)
  • startdate   (yyyy-mm-dd)
  • enddate   olderthan  (yyyy-mm-dd)
  •  true/false

yes

archiveEvents

  •  ids           (can pass one or more IDs seperated by comma)
  • type          (string)
  • startdate   (yyyy-mm-dd)
  • enddate   olderthan  (yyyy-mm-dd)
  • true/false

yes

...

Demo events API calls:

New classes for client APIs

...

  • New methods in ManagementServerImpl.java to delete and archive events.
  • New components in ManagementService.
  • New methods in EventDaoImpl to search and archive/delete events.

Logging and Debugging

All logs will go to management-server.log

Current limitations

UI flow

To be decided.