Open Stack

Thanks Eugene for putting together the various options.  Option 4 (and to a certain extent, Option 3) should work us for integrating the Device driver.  Is Option 4 is similar/same as per the https://review.openstack.org/#/c/20579<https://review.openstack.org/> with the Plugin Driver added?
Also, we talked about the Device Inventory Plugin Module to explicitly add devices to the system (with a separate DB Schema). Will this be supported? Also, can the vendor driver implement the logic of device selection as against the Plugin Driver/Device Scheduler choosing the device ?

Also, to get the end to end vendor driver integration, need support for exception handling on the Agent side so that if there are any exceptions/errors happen while configuring the device, the device driver can propagate it to the Agent and Plugin.

Regards,
Pattabi

From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Sunday, April 28, 2013 11:37 PM
To: OpenStack Development Mailing List
Cc: Youcef Laribi
Subject: [openstack-dev] Fwd: [Quantum][LBaaS] LBaaS development plan for Havana

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<http://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<mailto: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<mailto: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<mailto: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<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<mailto: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<mailto: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/8d3f43fe/attachment.html>