All points are good, but RootHistory object now is being created by guestagent while mysql datastore prepare call. Delegating all responsibilities to Conductor would give us next benefits: 1. Breaking guest -> back-end connectivity. 2. Keeping taskmanager generic (already said, need to take into accout non-ACL datastores) 3. Letting conductor doing it's job - executing tasks which are required back-end connectivity.
My current patch is not giving us points [1] and [2] since trove cannon manage it's own extension. 2013/12/20 Ed Cranford <[email protected]> > Fair enough, original scope for conductor was just heartbeats > anyway--backups were more of an added bonus if anything to reduce that db > dependency. > Denis' patch at present just makes taskmanager take care of it, and it's > simple enough to do that way. > > > On Fri, Dec 20, 2013 at 11:16 AM, Tim Simpson > <[email protected]>wrote: > >> >> whose proposed future phases include turning conductor into a source >> of truth for trove to ask about instances, and then using its own datastore >> separate from the host db anyway. >> >> IIRC this was to support such ideas as storing the heart beat or service >> status somewhere besides the Trove database. So let's say that instead of >> having to constantly update the heart beat table from the guest it was >> possible to ask Rabbit when the last time the guest tried to receive a >> message and use that as the heartbeat timestamp instead. This is what >> Conductor was meant to support - the ability to not force a guest to have >> to send back heart beat info to a database if there was an RPC technology >> dependent way to get that info which Conductor knew about. >> >> I don't agree with the idea that all information on a guest should live >> only in Conductor. Under this logic we'd have no backup information in the >> Trove database we could use when listing backups and would have to call >> Conductor instead. I don't see what that buys us. >> >> Similarly with the RootHistory object, it lives in the database right >> now which works fine because anytime Root is enabled it's done by Trove >> code which has access to that database anyway. Moving root history to >> Conductor will complicate things without giving us any benefit. >> >> Thanks, >> >> Tim >> >> ------------------------------ >> *From:* Ed Cranford [[email protected]] >> *Sent:* Friday, December 20, 2013 10:13 AM >> >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [trove] Dropping connectivity from >> guesagent to Trove back-end >> >> Conductor was the first phase of >> https://wiki.openstack.org/wiki/Trove/guest_agent_communication whose >> proposed future phases include turning conductor into a source of truth for >> trove to ask about instances, and then using its own datastore separate >> from the host db anyway. >> The purpose of the root history table is to keep information in a place >> even an instance with root cannot reach, so we essentially have a warranty >> seal on the instance. The thinking at was if that status was kept on the >> instance, intrepid users could potentially enable root, muck about, and >> then manually remove root. By putting that row in a table outside the >> instance there's no question. >> >> Phase 2 of the document above is to make conductor the source of truth >> for information about an instance, so taskman will start asking conductor >> instead of fetching the database information directly. So I think the next >> step for removing this is to give conductor a method taskman can call to >> get the root status from the extant table. >> >> Phase 3 then seeks to give conductor its own datastore away from the >> original database; I think that's the right time to migrate the root >> history table, too. >> >> >> On Fri, Dec 20, 2013 at 9:44 AM, Denis Makogon <[email protected]>wrote: >> >>> 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 >>> >>> >> >> >> -- >> [email protected] >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Ed Cranford > [email protected] > > _______________________________________________ > 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
