Open Stack

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