Re: [openstack-dev] [Solum] Nominating Vijendar Komalla for Solum core

[Ed Cranford]

+1
On Feb 2, 2016 4:07 PM, "James Y. Li"  wrote:

> +1
>
>
> On Tue, Feb 2, 2016 at 1:33 PM, Devdatta Kulkarni <
> devdatta.kulka...@rackspace.com> wrote:
>
>> Hi team,
>>
>> I would like to propose Vijendar Komalla for our core team. Vijendar has
>> been actively
>> contributing to Solum for several months now submitting patches,
>> providing great reviews,
>> and participating actively in our IRC meetings and on Solum IRC channel.
>> You can find Vijendar's contributions at [1][2].
>>
>> Please respond with your votes.
>>
>> Regards,
>> Devdatta
>>
>> [1] http://stackalytics.com/?module=solum&user_id=vijendar-komalla
>> [2]
>> http://stackalytics.com/?module=python-solumclient&user_id=vijendar-komalla
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][Solum] Request for feedback on new API resource

[Ed Cranford]

The app-resource spec [1] is as much documentation as we have on the new 
resources at present. It does illustrate some imagined healthy interactions 
with the proposed API, though looking at the mentioned Glance example I can see 
several ways we can improve our specs, for example by explaining more verbosely 
not just what each response might look like, but conceptually what has been 
asked for and what is being returned. There is clear precedent for modifying 
specs after ratification, so there should be no problem modifying even the 
app-resource spec to make our goals clearer.


The linked review [2] is the first of a planned series of such with the goal of 
implementing that spec. It creates a new data model for one of the three 
proposed resources and then exposes CRUD actions on that resource. Future 
reviews will incrementally add the other resources, add stronger data 
validation, integrate the new resources into the engine, and finally deprecate 
the obsolete resources and interactions.


We appreciate your advice on cleaner reviews and better design, especially 
since we're asking that you take the time to look over them, but we are 
primarily seeking your advice on our adherence to the API WG's guidelines, and 
if amending the spec to add detail and clarity is necessary we won't hesitate.


Thank you very much for your help.


[1] 
https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst

[2] https://review.openstack.org/#/c/185147/



From: Everett Toews 
Sent: Tuesday, June 23, 2015 8:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api][Solum] Request for feedback on new API 
resource

On Jun 18, 2015, at 3:07 PM, Devdatta Kulkarni 
mailto:devdatta.kulka...@rackspace.com>> wrote:

Hi, API WG team,

In Solum, recently we have been working on some changes to our REST API.

Basically, we have introduced a new resource ('app'). The spec for this has 
been accepted by Solum cores.
https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst

Right now we have a patch for review implementing this spec:
https://review.openstack.org/#/c/185147/

If it is not too much to request, I was wondering if someone from your team can 
take a look
at the spec and the review, to see if we are not violating any of your 
guidelines.

Thank you for your help.

- Devdatta

Do you have this API documented anywhere?

Is there a spec or similar for this API change?

In our experience, it's best to consider the API design apart from the 
implementation. The separation of concerns makes for a cleaner review and a 
better design. The Glance team did a good job of this in their Artifact 
Repository API specification [1].

Regards,
Everett

[1] https://review.openstack.org/#/c/177397/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum][Mistral] Help with a patch

[Ed Cranford]

The problem was caused by references to stackforge/python-mistralclient.git in 
contrib/devstack/lib/mistral; our devstack job in Jenkins was failing because 
it could not clone the client [1].


Merging [2] updated those references to their new openstack-owned locations.


Our issues are resolved.

Thank you for your attention.


[1] 
http://logs.openstack.org/52/191952/4/check/gate-solum-devstack-dsvm/409f9ab/logs/devstacklog.txt.gz#_2015-06-16_21_30_35_227

[2] https://review.openstack.org/#/c/192754/


From: Renat Akhmerov 
Sent: Tuesday, June 23, 2015 3:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum][Mistral] Help with a patch

Can you please confirm that the issue has been fixed?

The thing is AFAIK Solum was using the old version of Mistral API that is no 
longer supported (was announced a couple of months ago) so I just want to make 
sure you're using the new API.

Renat Akhmerov
@ Mirantis Inc.



On 18 Jun 2015, at 20:11, Nikolay Makhotkin 
mailto:nmakhot...@mirantis.com>> wrote:

Hi, Devdatta!

Thank you for catching this and for the patch. I already reviewed it and it has 
been merged.

--
Best Regards,
Nikolay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Addition to solum core

[Ed Cranford]

Thank you all very much.

On 1/5/15, 12:54 PM, "Adrian Otto"  wrote:

>Solum cores,
>
>Thanks for your votes. Ed has been added to the solum-core group.
>
>Cheers,
>
>Adrian
>
>On Dec 26, 2014, at 11:56 PM, Adrian Otto 
>wrote:
>
>> Solum cores,
>> 
>> I propose the following addition to the solum-core group[1]:
>> 
>> + Ed Cranford (ed--cranford)
>> 
>> Please reply to this email to indicate your votes.
>> 
>> Thanks,
>> 
>> Adrian Otto
>> 
>> [1] https://review.openstack.org/#/admin/groups/229,members Current
>>Members
>> 
>> ___
>> OpenStack-dev mailing list
>> 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


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

Re: [openstack-dev] [Solum] Core Reviewer Change

[Ed Cranford]

Happy Corethday to the both of you!

On 10/1/14, 1:10 PM, "Adrian Otto"  wrote:

>Thanks everyone for your feedback on this. The adjustments have been made.
>
>Regards,
>
>Adrian
>
>On Sep 30, 2014, at 10:03 AM, Adrian Otto 
>wrote:
>
>> Solum Core Reviewer Team,
>> 
>> I propose the following change to our core reviewer group:
>> 
>> -lifeless (Robert Collins) [inactive]
>> +murali-allada (Murali Allada)
>> +james-li (James Li)
>> 
>> Please let me know your votes (+1, 0, or -1).
>> 
>> Thanks,
>> 
>> Adrian
>> 
>> ___
>> OpenStack-dev mailing list
>> 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


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

Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best implementation practices?

[Ed Cranford]

So it does, I hadn't realized that. The earlier message mentioned using a 
command-line tool to produce pretty graph images, and I figured I knew just the 
tool for the job.

Since you're already indirectly using Graphviz, if you're only using PlantUML 
for processing the output of umlgen.py into a PNG, why not skip a step and 
generate the Graphviz input file yourself?
Granted, it'll take some work to build a similar visual style--I see elaborate 
record nodes in your future--but you don't have to be bound to PlantUML if you 
don't want to be.
I've used Graphviz before for a few applications, and if I can help get you 
started with building dot files, let me know.

That said, weighing effort against result, you may just be better off sticking 
with Plant at least in the short term.
I'm sorry I can't suggest a simpler alternative for you right now.

From: Dmitry Teselkin mailto:dtesel...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 2, 2014 at 12:05 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best 
implementation practices?

Hi,

GraphViz is alreary used by Plant UML to produce output PNG file, see 'image 
generation chain' below:
* umlgen.py walks through MuranoPL class(es) and generated temporary file which 
contains Plant UML definitions for the entire graph
* Plant UML is called with that file as input
* Plant UML processes input file somehow and uses GraphViz to build output image



On Tue, Apr 1, 2014 at 11:25 PM, Ed Cranford 
mailto:ed.cranf...@rackspace.com>> wrote:
What about Graphviz?

On 4/1/14, 1:34 PM, "Timur Sufiev" 
mailto:tsuf...@mirantis.com>> wrote:

>Hello!
>
>Recently we've made an attempt to make MuranoPL class definitions more
>conceivable for everyone, and decided to use UML diagrams for that
>purpose. The most obvious (and quick) solution was to use a well-known
>tool [1], the command-line script which uses it is almost ready [2],
>and the final result seems quite satisfying to us [3] (pictures are
>drawn using current version of script). Moreover, we liked these
>diagrams so much that decided to show them also in Murano's WebUI
>(right after the uploaded App Package has been validated).
>
>But we're little uncertain about using Java-based tool in the long
>run: it doesn't seem to fit very well with OpenStack common practices.
>So could you advice some good enough Python and/or Javascript library
>for generating UML diagrams? The most important criteria is an ability
>to produce graphics as beautiful as Plant UML does.
>
>[1] http://plantuml.sourceforge.net/
>[2] https://review.openstack.org/#/c/83348/
>[3]
>https://www.dropbox.com/sh/pesyejyjo624o34/fCe1_OM-OH#lh:null-io.murano.En
>vironment.png
>
>--
>Timur Sufiev
>
>___
>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<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com<http://www.mirantis.com/>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best implementation practices?

[Ed Cranford]

What about Graphviz?

On 4/1/14, 1:34 PM, "Timur Sufiev"  wrote:

>Hello!
>
>Recently we've made an attempt to make MuranoPL class definitions more
>conceivable for everyone, and decided to use UML diagrams for that
>purpose. The most obvious (and quick) solution was to use a well-known
>tool [1], the command-line script which uses it is almost ready [2],
>and the final result seems quite satisfying to us [3] (pictures are
>drawn using current version of script). Moreover, we liked these
>diagrams so much that decided to show them also in Murano's WebUI
>(right after the uploaded App Package has been validated).
>
>But we're little uncertain about using Java-based tool in the long
>run: it doesn't seem to fit very well with OpenStack common practices.
>So could you advice some good enough Python and/or Javascript library
>for generating UML diagrams? The most important criteria is an ability
>to produce graphics as beautiful as Plant UML does.
>
>[1] http://plantuml.sourceforge.net/
>[2] https://review.openstack.org/#/c/83348/
>[3] 
>https://www.dropbox.com/sh/pesyejyjo624o34/fCe1_OM-OH#lh:null-io.murano.En
>vironment.png
>
>-- 
>Timur Sufiev
>
>___
>OpenStack-dev mailing list
>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

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Ed Cranford]

+1 amcrn


On Thu, Jan 2, 2014 at 6:30 AM, Ilya Sviridov wrote:

> Hello Trove team
> Hello Michael
>
> I believe that Auston does a great job and personally think that his
> reviews are always thorough and reasonable.
> But It is surprising to not to see Denis Makogon (dmakogon,
> denis_makogon) as candidate to cores.
>
> He is well known active community player driving HEAT integration and
> Cassandra support in Trove. He takes part in all technical discussions
> and infrastructure as well.
> Also Denis actively helps to newcomers and always responsive in IRC chat.
>
> Just looking at his code review statistic [1] [2] [3] and trove weekly
> meeting participation [4] I astonished why there is no his name in the
> first email.
>
> [1] http://www.russellbryant.net/openstack-stats/trove-reviewers-180.txt
> [2] http://www.russellbryant.net/openstack-stats/trove-reviewers-90.txt
> [3] http://www.russellbryant.net/openstack-stats/trove-reviewers-30.txt
> [4] http://eavesdrop.openstack.org/meetings/trove/2013/
>
> With best regards,
> Ilya Sviridov
>
>
>
> On Tue, Dec 31, 2013 at 3:34 PM, Paul Marshall
>  wrote:
> > +1
> >
> > On Dec 30, 2013, at 1:13 PM, Vipul Sabhaya  wrote:
> >
> >> +1
> >>
> >> Sent from my iPhone
> >>
> >> On Dec 30, 2013, at 10:50 AM, Craig Vyvial  wrote:
> >>
> >>> +1
> >>>
> >>>
> >>> On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill 
> wrote:
> >>> +1
> >>>
> >>> On Dec 27, 2013, at 4:48 PM, Michael Basnight 
> wrote:
> >>>
>  Howdy,
> 
>  Im proposing Auston McReynolds (amcrn) to trove-core.
> 
>  Auston has been working with trove for a while now. He is a great
> reviewer. He is incredibly thorough, and has caught more than one critical
> error with reviews and helps connect large features that may overlap
> (config edits + multi datastores comes to mind). The code he submits is top
> notch, and we frequently ask for his opinion on architecture / feature /
> design.
> 
>  https://review.openstack.org/#/dashboard/8214
>  https://review.openstack.org/#/q/owner:8214,n,z
>  https://review.openstack.org/#/q/reviewer:8214,n,z
> 
>  Please respond with +1/-1, or any further comments.
>  ___
>  OpenStack-dev mailing list
>  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
> >>>
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> 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
> >
> >
> > ___
> > OpenStack-dev mailing list
> > 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
>



-- 
ed.cranf...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

[Ed Cranford]

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 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.cranf...@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 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 
>>
>>>  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
&

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

[Ed Cranford]

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 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 
>
>>  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 
>>
>>>  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]
>>> *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. B