Waines, Greg <greg.wai...@windriver.com> wrote:
Sam,
Two other more higher-level points I wanted to discuss with you about Masaraki.
First,
so I notice that you are doing both monitoring, auto-recovery and even host
maintenance
type functionality as part of the Masaraki architecture.
are you open to some configurability (enabling/disabling) of these capabilities
?
I can't speak for Sampath or the Masakari developers, but the monitors
are standalone components. Currently they can only send notifications
in a format which the masakari-api service can understand, but I guess
it wouldn't be hard to extend them to send notifications in other
formats if that made sense.
e.g. OPNFV guys would NOT want auto-recovery, they would prefer that fault
events
get reported to Vitrage ... and eventually filter up to
Aodh Alarms that get
received by VNFManagers which would be responsible for the
recovery.
e.g. some deployers of openstack might want to disable parts or all of your
monitoring,
if using other mechanisms such as Zabbix or Nagios for the host
monitoring (say)
Yes, exactly! This kind of configurability and flexibility which
would allow each cloud architect to choose which monitoring / alerting
/ recovery components suit their requirements best in a "mix'n'match"
fashion, is exactly what we are aiming for with our modular approach
to the design of compute plane HA. If the various monitoring
components adopt a driver-based approach to alerting and/or the
ability to alert via a lowest common denominator format such as simple
HTTP POST of JSON blobs, then it should be possible for each cloud
deployer to integrate the monitors with whichever reporting dashboards
/ recovery workflow controllers best satisfy their requirements.
Second, are you open to configurably having fault events reported to
Vitrage ?
Again I can't speak on behalf of the Masakari project, but this sounds
like a great idea to me :)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
