Open Stack

Hi Pattabi,

Yes, option 4 is about the architecture proposed in that patch on review.
Device inventory is also planned. I've already filed corresponding
blueprint. In fact, there was already a bp about that ("device
management"), but I decided to file the new one with more appropriate name.

> Also, can the vendor driver implement the logic of device selection as
against the Plugin Driver/Device Scheduler choosing the device ?
Sure. I think that could be done in plugin driver the first option (plugin
driver is vendor-specific just like device driver).

> 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.
That will be done in two ways: first of all PENDING_ statuses will be
implemented so each object receives PENDING_ status and then final status
after driver/agent acknowledges the operation. Need to think about how to
store possible errors.

Thanks,
Eugene.



On Mon, Apr 29, 2013 at 10:25 PM, Pattabi Ayyasami <pattabi at brocade.com>wrote:

> 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 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/6abdb787/attachment.html>