Bug 1290099 - Notifications about usage events for non mysql datastores are blocked in the default configuration
Summary: Notifications about usage events for non mysql datastores are blocked in the ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-trove
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Victoria Martinez de la Cruz
QA Contact: Luigi Toscano
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-09 16:30 UTC by Luigi Toscano
Modified: 2016-06-29 20:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-29 20:39:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.