add generic monitor framework

Instead of having a central file or group of files to
describe what data resources should be monitored.  The
content of these files will depend on what core system
monitoring is used ((e.g. Nagios or Monasca).

It's desirable to have each recipe describes what
it wants be monitored in generic way such that various system
monitors can understand and convert these into their format.

If a recipe wishes to register itself to system monitor, it
inherits monitor bbclass and use MONITOR_SERVICE_PACKAGES and
MONITOR_SERVICE_<package name> to indicate what processes
should should be monitored.  Also MONITOR_CHECKS_<package name>
variale can be used to pass list of scripts which will be run
on target and if any of these scripts fail then will report.

Eventually monitor.bbclass will be expanded to allow recipe
to describe more complicated information passed down to
system monitor (e.g. Nagios or Monasca)

Signed-off-by: Vu Tran <vu.tran@windriver.com>

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

1 files changed, 1 insertions, 0 deletions

diff --git a/meta-openstack/recipes-extended/images/openstack-image-controller.bb b/meta-openstack/recipes-extended/images/openstack-image-controller.bb
index d2cc90f..a410acf 100644
--- a/meta-openstack/recipes-extended/images/openstack-image-controller.bb
+++ b/meta-openstack/recipes-extended/images/openstack-image-controller.bb
@@ -21,6 +21,7 @@ POST_KEYSTONE_SETUP_COMMAND = "/etc/keystone/hybrid-backend-setup"
 inherit core-image
 inherit openstack-base
 inherit identity
+inherit monitor
 
 # Ensure extra space for guest images, and rabbit MQ has a hard coded
 # check for 2G of free space, so we use 5G as a starting point.