[openstack-dev] [Trove] Guest RPC API improvements. Messages, topics, queues, consumption.

Denis Makogon dmakogon at mirantis.com
Fri Oct 31 09:32:37 UTC 2014


Hello, Stackers/Trovers.



I’d like to start discussion about how do we use guestagent API that will
eventually be evaluated as a spec. For most of you who well-known with
Trove’s codebase knows how do Trove acts when provisioning new instance.

I’d like to point out next moments:

   1.

   When we provision new instance we expect that guest will create its
   topic/queue for RPC messaging needs.
   2.

   Taskmanager doesn’t validate that guest is really up before sending
   ‘prepare’ call.

And here comes the problem, what if guest wasn’t able to start properly and
consume ‘prepare’ message due to certain circumstances? In this case
‘prepare’ message would never be consumed.


 Me and Sergey Gotliv were looking for proper solution for this case. And
we end up with next requirements for provisioning workflow:

   1.

   We must be sure that ‘prepare’ message will be consumed by guest.
   2.

   Taskmanager should handle topic/queue management for guest.
   3.

   Guest just need to consume income messages for already existing
   topic/queue.

 As concrete proposal (or at least topic for discussions) i’d like to
discuss next improvements:

We need to add new guest RPC API that will represent “ping-pong” action. So
before sending any cast- or call-type messages we need to make sure that
guest is really running.


Pros/Cons for such solution:

   1.

   Guest will do only consuming.
   2.

   Guest would not manage its topics/queues.
   3.

   We’ll be 100% sure that no messages would be lost.
   4.

   Fast-fail during provisioning.
   5.

   Other minor/major improvements.



Thoughts?


P.S.: I’d like to discuss this topic during upcoming Paris summit (during
contribution meetup at Friday).



Best regards,

Denis Makogon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141031/56606997/attachment.html>


More information about the OpenStack-dev mailing list