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 [dmako...@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.simp...@rackspace.com<mailto:tim.simp...@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 [dmako...@mirantis.com<mailto:dmako...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to