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 <[email protected]> > 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 [[email protected]] > *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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
