Open Stack

    Goodday, OpenStack DВaaS community.


    I'd like to start conversation about dropping connectivity from In-VM
guestagent and Trove back-end.

    Since Trove has conductor service which interacts with agents via MQ
service, we could let it deal with any back-end required operations
initialized by guestagent.

    Now conductor deals with instance status notifications and backup
status notifications. But guest still have one more operation which
requires back-end connectivity - database root-enabled reporting [1]. After
dealing with it we could finally drop connectivity [2].

Since not each database have root entity (not even ACL at all) it would be
incorrect to report about root enabling on server-side because
server-side(trove-taskmanager) should stay common as it possible.

    My first suggestion was to extend conductor API [3] to let conductor
write report to Trove back-end. Until Trove would reach state when it would
support multiple datastore (databases) types current patch would work fine
[4], but when Trove would deliver, suppose, Database (without ACL) it would
be confusing when after instance provisioning user will find out that some
how root was enabled, but Database doesn't have any ACL at all.

    My point is that Trove Conductor must handle every database (datastore
in terms of Trove) specific operations which are required back-end
connection. And Trove server-side (taskmanager) must stay generic and
perform preparation tasks, which are independent from datastore type.

 [1] https://github.com/openstack/trove/blob/master/bin/trove-guestagent#L52

[2] https://bugs.launchpad.net/trove/+bug/1257489

[3] https://review.openstack.org/#/c/59410/5

[4] https://review.openstack.org/#/c/59410/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/de4b1400/attachment.html>