Bug 1290099 - Notifications about usage events for non mysql datastores are blocked in the default configuration
Notifications about usage events for non mysql datastores are blocked in the ...
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-trove (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
medium Severity medium
: ---
: 8.0 (Liberty)
Assigned To: Victoria Martinez de la Cruz
Luigi Toscano
: ZStream
Depends On:
  Show dependency treegraph
Reported: 2015-12-09 11:30 EST by Luigi Toscano
Modified: 2016-06-29 16:39 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-06-29 16:39:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Luigi Toscano 2015-12-09 11:30:30 EST
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.

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):
Comment 1 Nick Barcet 2016-06-29 16:39:20 EDT
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.