<div dir="ltr">Fair enough, original scope for conductor was just heartbeats anyway--backups were more of an added bonus if anything to reduce that db dependency.<div>Denis' patch at present just makes taskmanager take care of it, and it's simple enough to do that way.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 11:16 AM, Tim Simpson <span dir="ltr"><<a href="mailto:tim.simpson@rackspace.com" target="_blank">tim.simpson@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma"><div class="im">>> <span style="font-family:'Times New Roman';font-size:16px">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.</span>
</div><div><font face="Times New Roman" size="3"><br>
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.</font></div>
<div><font face="Times New Roman" size="3"><br>
</font></div>
<div><font face="Times New Roman" size="3">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.</font></div>
<div><font face="Times New Roman" size="3"><br>
</font></div>
<div><font face="Times New Roman" size="3">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.</font></div>
<div><font face="Times New Roman" size="3"><br>
</font></div>
<div><font face="Times New Roman" size="3">Thanks,</font></div>
<div><font face="Times New Roman" size="3"><br>
</font></div>
<div><font face="Times New Roman" size="3">Tim</font></div>
<div><font face="Times New Roman" size="3"><br>
</font></div>
<div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Ed Cranford [<a href="mailto:ed.cranford@gmail.com" target="_blank">ed.cranford@gmail.com</a>]<br>
<b>Sent:</b> Friday, December 20, 2013 10:13 AM<div><div class="h5"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">
<div>Conductor was the first phase of <a href="https://wiki.openstack.org/wiki/Trove/guest_agent_communication" target="_blank">https://wiki.openstack.org/wiki/Trove/guest_agent_communication</a> 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.<br>
</div>
<div>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.</div>
<div><br>
<div>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.</div>
</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Dec 20, 2013 at 9:44 AM, Denis Makogon <span dir="ltr">
<<a href="mailto:dmakogon@mirantis.com" target="_blank">dmakogon@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.
<br>
Prof: <a href="https://github.com/openstack/trove/blob/master/trove/extensions/mysql/service.py" target="_blank">
https://github.com/openstack/trove/blob/master/trove/extensions/mysql/service.py</a><br>
</div>
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.
<div>
<div><br>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/12/20 Tim Simpson <span dir="ltr"><<a href="mailto:tim.simpson@rackspace.com" target="_blank">tim.simpson@rackspace.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>It seems like if you follow my one (hopefully last) suggestion on this pull request, it will solve the issue you're tackling: <a href="https://review.openstack.org/#/c/59410/5" target="_blank">https://review.openstack.org/#/c/59410/5</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b>From:</b> Denis Makogon [<a href="mailto:dmakogon@mirantis.com" target="_blank">dmakogon@mirantis.com</a>]<br>
<b>Sent:</b> Friday, December 20, 2013 8:58 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end<br>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">
<div>
<div>Thanks for response, Tim.<br>
<br>
</div>
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.<br>
</div>
<div><br>
It would be nice to have consistent instance states for each datastore types and version.<br>
<br>
</div>
<div>Are there any objections about letting conductor deal with it ?<br>
<br>
</div>
<div><br>
<br>
Best regards, <br>
Denis Makogon<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/12/20 Tim Simpson <span dir="ltr"><<a href="mailto:tim.simpson@rackspace.com" target="_blank">tim.simpson@rackspace.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">Hi Denis,
<div><br>
</div>
<div>The plan from the start with Conductor has been to remove any guest connections to the database. So any lingering ones are <span style="font-size:10pt">omissions which should be dealt with.</span></div>
<div>
<div><br>
</div>
<div>>> <span style="font-family:Arial;font-size:15px;text-align:justify;text-indent:48px">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.</span></div>
<div><span style="font-family:Arial;font-size:15px;text-align:justify;text-indent:48px"><br>
</span></div>
</div>
<div>
<div><span style="font-family:Arial;font-size:15px;text-align:justify;text-indent:48px">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.</span></div>
</div>
<div><span style="font-family:Arial;font-size:15px;text-align:justify;text-indent:48px"><br>
</span></div>
<div><span style="font-family:Arial;font-size:15px;text-align:justify;text-indent:48px">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. </span></div>
<div align="justify" style="font-family:'Segoe UI',Helvetica,Arial,sans-serif;margin-top:0px;margin-bottom:0px">
<font color="black" face="Arial"><span style="font-size:15px"><br>
</span></font></div>
<div>Thanks,</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b>From:</b> Denis Makogon [<a href="mailto:dmakogon@mirantis.com" target="_blank">dmakogon@mirantis.com</a>]<br>
<b>Sent:</b> Friday, December 20, 2013 7:04 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end<br>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> Goodday, OpenStack DВaaS community.</span></p>
<br>
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"></span><br>
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"></span>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> I'd like to start conversation about dropping connectivity from In-VM
guestagent and Trove back-end.</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> 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.</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> 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].<br>
</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-indent:36pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">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.</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> 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.</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"> 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.<br>
</span></p>
<br>
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"></span>
<p align="JUSTIFY" style="margin-bottom:0in">[1] <a href="https://github.com/openstack/trove/blob/master/bin/trove-guestagent#L52" target="_blank">
https://github.com/openstack/trove/blob/master/bin/trove-guestagent#L52</a></p>
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal"></span>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">[2]</span><a href="https://bugs.launchpad.net/trove/+bug/1257489" style="text-decoration:none" target="_blank"><span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">
</span><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://bugs.launchpad.net/trove/+bug/1257489</span></a></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">[3]</span><a href="https://review.openstack.org/#/c/59410/5" style="text-decoration:none" target="_blank"><span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">
</span><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://review.openstack.org/#/c/59410/5</span></a></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt;text-align:justify">
<span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">[4]</span><a href="https://review.openstack.org/#/c/59410/" style="text-decoration:none" target="_blank"><span style="vertical-align:baseline;font-variant:normal;font-style:normal;font-size:15px;background-color:transparent;text-decoration:none;font-family:Arial;font-weight:normal">
</span><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://review.openstack.org/#/c/59410/</span></a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<a href="mailto:ed.cranford@gmail.com" target="_blank">ed.cranford@gmail.com</a> </div>
</div>
</div></div></div>
</div>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ed Cranford<br><a href="mailto:ed@slumberheart.com" target="_blank">ed@slumberheart.com</a>
</div>