Open Stack

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 <ed at slumberheart.com>

> 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 <tim.simpson at rackspace.com>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 [ed.cranford at gmail.com]
>> *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 <dmakogon at mirantis.com>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 <tim.simpson at rackspace.com>
>>>
>>>>  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 [dmakogon at mirantis.com]
>>>> *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 <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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>  --
>> ed.cranford at gmail.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Ed Cranford
> ed at slumberheart.com
>
> _______________________________________________
> 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/acd446f8/attachment.html>