Bug 1290099

Summary:	Notifications about usage events for non mysql datastores are blocked in the default configuration
Product:	Red Hat OpenStack	Reporter:	Luigi Toscano <ltoscano>
Component:	openstack-trove	Assignee:	Victoria Martinez de la Cruz <vimartin>
Status:	CLOSED WONTFIX	QA Contact:	Luigi Toscano <ltoscano>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0 (Liberty)	CC:	apevec, lhh, nbarcet, pmackinn, srevivo
Target Milestone:	---	Keywords:	ZStream
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-29 20:39:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Luigi Toscano 2015-12-09 16:30:30 UTC

Description of problem:
The default configuration file /etc/trove/trove-taskmanager.conf (part of the openstack-trove-taskmanager package) contains a specific setting for notification_service_id:

notification_service_id = mysql:2f3ff068-2bfb-4f70-9a9d-a6bb65bc084b

The spec file creates this file by copying the default example (etc/trove/trove-taskmanager.conf.sample).

With this settings, only notifications for events related to the mysql datastore are sent. Symptoms: errors in trove-taskmanager.log: 

ERROR trove.taskmanager.models [-] Datastore ID for Manager (mariadb) is not configured


On the other side, the default value of the key seems to contain default UUIDs for all datastores.


Suggested path of action:
1) enable all supported datastores for our builds;
2) document the need to add additional values (comma-separated) for other datastores, if needed.

or 
1') remove the key notification_service_id, relying on the default value, which should be checked for being a real sane default 
2') document the key anyway (users need to specify all the datastores for which they need a notification).

Version-Release number of selected component (if applicable):
openstack-trove-taskmanager-4.0.0-2.el7ost.noarch

Comment 1 Nick Barcet 2016-06-29 20:39:20 UTC

Based on customer feedback, and the constant message that support for commercially available database was an absolute must from the almost all of the customers we surveyed, we have came to the conclusion that we should rather concentrate our effort in having successful partnerships around Trove rather than building a fully open-source solution that will not benefit our customers.