Yes, right. Thanks Winson. Renat Akhmerov @ Mirantis Inc.
On 26 Feb 2014, at 01:39, W Chan <m4d.co...@gmail.com> wrote: > Sure. Let me give this some thoughts and work with you separately. Before > we speak up, we should have a proposal for discussion. > > > On Mon, Feb 24, 2014 at 9:53 PM, Dmitri Zimine <d...@stackstorm.com> wrote: > Winson, > > While you're looking into this and working on the design, may be also think > through other executor/engine communications. > > We talked about executor communicating to engine over 3 channels (DB, REST, > RabbitMQ) which I wasn't happy about ;) and put it off for some time. May be > it can be rationalized as part of your design. > > DZ. > > On Feb 24, 2014, at 11:21 AM, W Chan <m4d.co...@gmail.com> wrote: > >> Renat, >> >> Regarding your comments on change https://review.openstack.org/#/c/75609/, I >> don't think the port to oslo.messaging is just a swap from pika to >> oslo.messaging. OpenStack services as I understand is usually implemented >> as an RPC client/server over a messaging transport. Sync vs async calls are >> done via the RPC client call and cast respectively. The messaging transport >> is abstracted and concrete implementation is done via drivers/plugins. So >> the architecture of the executor if ported to oslo.messaging needs to >> include a client, a server, and a transport. The consumer (in this case the >> mistral engine) instantiates an instance of the client for the executor, >> makes the method call to handle task, the client then sends the request over >> the transport to the server. The server picks up the request from the >> exchange and processes the request. If cast (async), the client side >> returns immediately. If call (sync), the client side waits for a response >> from the server over a reply_q (a unique queue for the session in the >> transport). Also, oslo.messaging allows versioning in the message. Major >> version change indicates API contract changes. Minor version indicates >> backend changes but with API compatibility. >> >> So, where I'm headed with this change... I'm implementing the basic >> structure/scaffolding for the new executor service using oslo.messaging >> (default transport with rabbit). Since the whole change will take a few >> rounds, I don't want to disrupt any changes that the team is making at the >> moment and so I'm building the structure separately. I'm also adding >> versioning (v1) in the module structure to anticipate any versioning changes >> in the future. I expect the change request will lead to some discussion as >> we are doing here. I will migrate the core operations of the executor >> (handle_task, handle_task_error, do_task_action) to the server component >> when we agree on the architecture and switch the consumer (engine) to use >> the new RPC client for the executor instead of sending the message to the >> queue over pika. Also, the launcher for ./mistral/cmd/task_executor.py will >> change as well in subsequent round. An example launcher is here >> https://github.com/uhobawuhot/interceptor/blob/master/bin/interceptor-engine. >> The interceptor project here is what I use to research how oslo.messaging >> works. I hope this is clear. The blueprint only changes how the request and >> response are being transported. It shouldn't change how the executor >> currently works. >> >> Finally, can you clarify the difference between local vs scalable engine? I >> personally do not prefer to explicitly name the engine scalable because this >> requirement should be in the engine by default and we do not need to >> explicitly state/separate that. But if this is a roadblock for the change, >> I can put the scalable structure back in the change to move this forward. >> >> Thanks. >> Winson >> >> _______________________________________________ >> 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
