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

2014-10-31 Thread Denis Makogon
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-10-31 Thread Tim Simpson
Hi Denis,

It seems like the issue you're trying to solve is that these 'prepare' messages 
can't be consumed by the guest.
So, if the guest never actually comes online and therefore can't consume the 
prepare call, then you'll be left with the message in the queue forever.

If you use a ping-pong message, you'll still be left with a stray message in 
the queue if it fails.

I think the best fix is if we delete the queue when deleting an instance. This 
way you'll never have more queues in rabbit than are needed.

Thanks,

Tim



From: Denis Makogon [dmako...@mirantis.com]
Sent: Friday, October 31, 2014 4:32 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Guest RPC API improvements. Messages, topics, 
queues, consumption.


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

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


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

2014-10-31 Thread Denis Makogon
On Fri, Oct 31, 2014 at 7:49 PM, Tim Simpson tim.simp...@rackspace.com
wrote:

  Hi Denis,

  It seems like the issue you're trying to solve is that these 'prepare'
 messages can't be consumed by the guest.

Not only 'prepare' call. I want to point out that each RPC API call that
uses RPC 'cast' messaging type may remain for ever inside AMPQ service.

 So, if the guest never actually comes online and therefore can't consume
 the prepare call, then you'll be left with the message in the queue
 forever.

 Yes, it still may fail, but at least we can be sure that when we want to
'cast' something to guest it's alive and the only way to check if it's
alive to use 'call' messaging type, because if guest is down for some
reasons 'call' will fail as soon as possible.


  If you use a ping-pong message, you'll still be left with a stray
 message in the queue if it fails.

 Ok, let's discuss it. What do you thing would give us confidence that
guest is really up and ready to consume?


  I think the best fix is if we delete the queue when deleting an
 instance. This way you'll never have more queues in rabbit than are needed.

 I do agree that it may work. But as for me, it'll be more safe if
taskmanager will handle topic initializing(when instance gets created) and
canceling (when instance gets deleted).


  Thanks,

  Tim



Best regards,
Denis M.

  --
 *From:* Denis Makogon [dmako...@mirantis.com]
 *Sent:* Friday, October 31, 2014 4:32 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Trove] Guest RPC API improvements. Messages,
 topics, queues, consumption.

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


 ___
 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