Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/27ca3268/attachment.html>