Open Stack

Eugene,

Don't we want to follow the plugin/agent model instead of direct driver
call?
plugin/agent call preserves the same semantics of other services and in
addition you are riding on the coattails of the security mechanisms of mq.

How is the authentication done in the direct driver call?

Thanks
Vinay

On Mon, Nov 12, 2012 at 6:23 AM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:

> Hi folks,
>
> In the latest meeting we've mentioned several important architectural
> points including:
> - agents vs direct driver call
> - asynchronous execution
> - dispatching a generic REST call to a proper driver.
>
> I would like to present how Mirantis team sees this based on our previous
> experience with LBaaS and other openstack components.
>
> We need asynchronous execution in the sense that client gets immediate
> response while actual device configuration happens later.
> Workflow of such operation could look like following:
> 1) client makes REST call; receives an object it has created/modified with
> PENDING status
> 2) call is dispatched to a plugin, plugin creates/modifies/etc an object
> in the database
> 3) plugin calls driver to apply new configuration to specific device
> 4) driver finishes applying configuration, plugin updates DB object
> 5) client polls objectID and gets final status of operation.
>
> Now depending on approach we take, (3) could expand into different
> sequence of operations.
> One of the good options to choose could be using agent between plugin and
> drivers. In this case (3) expands to:
> 3.1 plugin posts message to mq
> 3.2. message is consumed by one of the running service agents
> 3.3. agent calls corresponding driver directly in synchronous way.
> 3.4. agent posts message upon completion.
> 3.5. plugin consumes the message and updates DB object with final status
>
> Such approach solves at least two potential problems:
> 1. plugin may be simplified since it is not required to implement
> call/work item queuing
> 2. Applying device configuration is time consuming task which could take
> seconds.
> Both plugin and agent has thread limit for any concurrent operations.
> Handling heavy workload in large deployments will be simple with several
> agents consuming messages from mq.
>
> Also this allows to create synchronous drivers since asyncness will be
> handled by mq + agent.
>
> Another option could be calling drivers directly without any asyncness at
> all while preserving above workflow (1-5).
> That could work as temporary fast solution while allowing to split it to
> "plugin + agent approach" relatively easily.
>
> Regarding the dispatching REST calls to proper driver:
> In fact, VIP object should contain reference to particular device it is
> created at.
> http://wiki.openstack.org/LBaaS/CoreResourceModel/proposal misses that
> device management part, I think it was just implied there.
> Every balancer-related object references the VIP and hence references the
> specific device where it was created.
> E,g, when a call for any object is made, plugin needs to extract device
> type from DB following those references and later plugin or agent will use
> it to call particular driver.
>
> Thanks,
>  Eugene.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vinay Bannai
Email: vbannai at gmail.com
Google Voice: 415 938 7576
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/4bdcbe73/attachment.html>