Unfortunately, Trove cannot manage it's own extensions, so if, suppose, i would try to get provisioned cassandra instance i would be still possible to check if root enabled. Prof: https://github.com/openstack/trove/blob/master/trove/extensions/mysql/service.py There are no checks for datastore_type, service just loads root model and that's it, since my patch create root model, next API call (root check) will load this model.
2013/12/20 Tim Simpson <[email protected]> > Because the ability to check if root is enabled is in an extension which > would not be in effect for a datastore with no ACL support, the user would > not be able to see that the marker for root enabled was set in the Trove > infrastructure database either way. > > By the way- I double checked the code, and I was wrong- the guest agent > was *not* telling the database to update the root enabled flag. Instead, > the API extension had been updating the database all along after contacting > the guest. Sorry for making this thread more confusing. > > It seems like if you follow my one (hopefully last) suggestion on this > pull request, it will solve the issue you're tackling: > https://review.openstack.org/#/c/59410/5 > > Thanks, > > Tim > > ------------------------------ > *From:* Denis Makogon [[email protected]] > *Sent:* Friday, December 20, 2013 8:58 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [trove] Dropping connectivity from > guesagent to Trove back-end > > 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 > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
