[openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

Denis Makogon dmakogon at mirantis.com
Fri Dec 20 14:58:41 UTC 2013


Thanks for response, Tim.

As i said, it would be confusing situation when database which has no ACL
would be deployed by Trove with root enabled - this looks very strange
since user allowed to check if root enabled. I think in this case Conductor
should be _that_ place which should contain datastore specific logic, which
requires back-end connectivity.

It would be nice to have consistent instance states for each datastore
types and version.

Are there any objections about letting conductor deal with it ?



Best regards,
Denis Makogon


2013/12/20 Tim Simpson <tim.simpson at rackspace.com>

>  Hi Denis,
>
>  The plan from the start with Conductor has been to remove any guest
> connections to the database. So any lingering ones are omissions which
> should be dealt with.
>
>  >> 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.
>
>  I agree that in the case of the root call Conductor should have another
> RPC method that gets called by the guest to inform it that the root entity
> was set.
>
>  I also agree that any code that can stay as common as possible between
> datastores should. However I don't agree that trove-taskmanager (by which I
> assume you mean the daemon) has to only be for common functionality.
>
>  Thanks,
>
>  Tim
>
>  ------------------------------
> *From:* Denis Makogon [dmakogon at mirantis.com]
> *Sent:* Friday, December 20, 2013 7:04 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [trove] Dropping connectivity from guesagent
> to Trove back-end
>
>        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/
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/15af614d/attachment.html>


More information about the OpenStack-dev mailing list