Open Stack

Folks,

Sorry, I forgot to 'reply all'.
Wiki page (https://wiki.openstack.org/wiki/Quantum/LBaaS/PluginDrivers
) contains
some possible ways of interacting between various components of lbaas.
Youcef, your model #5 is also possible, feel free to add it to the page.
(Btw, I used websequencediagrams.com to make pictures)

As for asynchronocity: I implied that 1st, 2nd, and 4th approach would use
rpc 'cast' method, which is non-blocking. Agent then will call some
plugin-side callback to acknowledge status of the object being CRUDed.
As for rest-proxy case (I hope I've chosen the right name for what Radware
wants) - I think that it could be implemented just in the same way. If not
then it would be responsibility of the driver or agent to provide that
async behavior.

In fact, I've been thinking a while about async drivers and came to
conclusion that it's an overhead, because once we start talking to some
in-quantum component via rpc it becomes in-quantum agent.
That has 2 consequences:
1) if you have such async driver, you should not use separate agent (or it
would be plugin->(rpc) driver->(rpc) agent, which is an overhead)
2) you can't use main advantage of agents: load distribution across
different hosts.
So currently I think we could be ok with 'sync' drivers until they do not
wait for corresponding agent.

Thanks,
Eugene.

---------- Forwarded message ----------
From: Eugene Nikanorov <enikanorov at mirantis.com>
Date: Fri, Apr 26, 2013 at 4:15 PM
Subject: Re: [Quantum][LBaaS] LBaaS development plan for Havana
To: Youcef Laribi <Youcef.Laribi at eu.citrix.com>


Hi Youcef,

I've added a page with workflows for cases that were described in the plan:
https://wiki.openstack.org/wiki/Quantum/LBaaS/PluginDrivers

Regarding the box descriptions - I was hoping their meaning didn't change
:) It's only that we now may have drivers at both plugin and agent side.

Thanks,
Eugene.



On Thu, Apr 25, 2013 at 11:22 PM, Youcef Laribi <Youcef.Laribi at eu.citrix.com
> wrote:

> Thanks Eugene. Could you for clarity add to the document a brief
> description of what each box in the diagram does, and what is the workflow
> of a user request for each of the 4 drivers you have in the picture?****
>
> ** **
>
> Thanks****
>
> Youcef****
>
> ** **
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Thursday, April 25, 2013 9:24 AM
> *To:* Sumit Naiksatam
> *Cc:* OpenStack Development Mailing List; Ilya Shakhat; Avishay
> Balderman; Mark McClain; Youcef Laribi; Salvatore Orlando
> *Subject:* Re: [Quantum][LBaaS] LBaaS development plan for Havana****
>
> ** **
>
> Sumit,****
>
> No, thanks for reminding! need to think how it will fit into the plan (at
> which step it would be easier to implement)****
>
> ** **
>
> Youcef, drivers are only vendor-specific in my diagram (both plugin-side
> drivers or agent-side drivers).****
>
> Device Inventory or scehduling don't belong to drivers, but drivers could
> rely on them.****
>
> ** **
>
> Thanks,****
>
> Eugene.****
>
> ** **
>
> On Thu, Apr 25, 2013 at 8:09 PM, Sumit Naiksatam <sumitnaiksatam at gmail.com>
> wrote:****
>
> Hi Eugene,****
>
> ** **
>
> Thanks. During the summit we discussed the notion of a logical
> loadbalancer/device which we later moved to calling a loadbalancer service
> instance (one or more tenant, as desired). Is this capture somewhere in the
> scheme of things?****
>
> ** **
>
> ~Sumit.****
>
> ** **
>
> On Thu, Apr 25, 2013 at 8:38 AM, Eugene Nikanorov <enikanorov at mirantis.com>
> wrote:****
>
> Hi folks,****
>
> ** **
>
> I've prepared a list of a major action items needed for futher development
> of multivendor and production-ready LBaaS:
> https://wiki.openstack.org/wiki/Quantum/LBaaS/HavanaPlan****
>
> ** **
>
> I'd be glad to here your feedback about it. ****
>
> I think we need to start discussing these items in more details.****
>
> ** **
>
> Aside from this list I imply that vendors will create their drivers
> choosing whatever architecture is reasonable for their solution, while
> quantum provides convenient way of integrating them.****
>
> Also, as you can see, some of action items (like service insertion or
> device inventory) have scope beyond LBaaS so I expect folks who are
> interested in other services to participate in corresponding discussions.*
> ***
>
> ** **
>
> Thanks,****
>
> Eugene.****
>
> ** **
>
> ** **
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/05d23ada/attachment.html>