Bug 1042279

Summary:	[RFE][ceilometer]: Alarm constrained by time-of-day or day-of-week
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-ceilometer	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	jruzicka, markmc, pbrady, yeylon
Target Milestone:	ga	Keywords:	FutureFeature
Target Release:	5.0 (RHEL 7)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/ceilometer/+spec/time-constrained-alarms
Whiteboard:	upstream_milestone_icehouse-3 upstream_status_implemented upstream_definition_approved
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 21:37:29 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/time-constrained-alarms.

Description:

Currently, alarm evaluation works the same way regardless of the time of the day or the day of the week.

However, it would be useful to have the flexibility to set the bar higher or lower at different times of the day or days of the week. For example to do one thing if the alarm condition occurs during normal working hours, but do something else  if it occurs at the weekend.

A typical usecase would be an autoscaling group with a more aggressive scale-up policy at the weekend (i.e. scaling up quicker & farther when the under-scaled alarm fires) because instance hours might be cheaper at this time, and operations man-power is generally less abundant (so that manual remediation, if required, would be more awkward).

This would not necessitate adding yet another alarm type (in addition to the existing threshold-oriented and meta-alarms). Instead this requirement could be met by  encoding the time constraints in the alarm definition and considering this as part of the generic alarm evaluation.

The fine-grained design decisions and implementation tasks would include:

* decide how many time-constraints may be associated with an individual alarm (1:1, or M:1 combined using logical OR)

* decide how the time-constraints associated with an alarm are accommodated within the alarm storage model
** if encoded directly in the alarm rule, then this would not require a substantive change to the schema via a DB migration

* decide how to represent the time-constraints in a concise and easily-understood way
** a convenient and widely-understood way of expressing such constraints would be via cron expressions (though such expressions are better suited to capturing specific times as opposed to time-ranges) 

* add the logic to enforce the time-constraints within the ceilometer.alarm.evaluator.Evaluator super-class, then modify the threshold and combination sub-classes such that assigned alarms do not transition into the alarm state if their time-constraints are not met

* add support for time-constraint to the pthyon-ceilometerclient client librray & CLI, such that alarms can be created with such constraints, these constraints can be retrieved and updated etc. 

Specification URL (additional information):

None