Open Stack

John,

To be clear, by putting the diagram out there, I'm not implying there is consensus or agreement on this, I'm trying to force a discussion, so people on the list can react to what is being proposed.

The only consensus we have so far is the LBaaS plugin component, and the LBaaS agent. But the "scheduler" discussion has dragged other pieces into focus, which are not well-understood today.

On your question about the "scheduler" synchronous/asynchronous interaction with vendor pieces, as I said before, I prefer all the vendor-pieces to be in one component, namely the driver, even if the driver needs to implement several interfaces in order to talk to several of the components in the diagram. This is my preference, but until we understand more about the other components, and their dependencies on each other, it is hard to see (at least for me) whether this can be realized.

Thanks,
Youcef

From: John Gruber [mailto:john.t.gruber at gmail.com]
Sent: Thursday, December 6, 2012 8:25 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Openstack-dev][Quantum][LBaaS] Quantum components needed for the LBaaS service

Youcef,

Thank you for the block diagram. I had a couple of questions:

>From your drawing, can I infer that the scheduler is to be provided as a python module and class and not a proper service interface? The decoupling through queue seems to be one of synchronous / asynchronous task scaling only. Why not a scheduler queue as well to allow the vendor line to be completely handled through AMQP messaging? The LBaaS vendor could create as simple or as complex a management system to interact with LBaaS through messaging. What are your thought about forcing the schedule coupling?

Is it safe to say that the other issues of thorny coupling you are worried about can be isolated to discrete functional areas where proper interface definitions and RPC could avoid them?

I agree with you BTW.  I've been writing some 'glue' for a project and finding other areas in Quantum itself which are too tightly tied to the data model of VM interfaces and it created a few thorns. It was a time consuming exercise to make Quantum functionality live behind an interface which would work simply through other vendor's interfaces as well.

This is our trade-off of time vs complexity I know...

John


On Wed, Dec 5, 2012 at 5:01 PM, Youcef Laribi <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>> wrote:
The discussion on scheduling has prompted me to think that there are several inter-linked components that we have so far not discussed in detail, and I'm worried that diving into implementation without understanding how the different components will eventually fit together will create us problems later on. For example, we haven't so far discussed the APIs for "service type" management (and this is creating confusion in other thread discussions), or for device management, as these have impact on the LBaaS piece. We need to understand the big picture of the components that will be in place, their dependencies, and the vendor-specific pieces and where they would be located.

To start this discussion I have drawn an initial picture with the components that I think would need to be in place. So let's start discussing the need for each component, its functions, where does it live (is it a Quantum plugin? is it something else?), what are the dependencies on the other components (in terms of interactions or DB sharing). The component diagram is here: http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Services+components.png

I want us to discuss this in a little bit more detail, before we get too much into implementation and realize the thorny issues later on.

Thanks
Youcef

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121206/bf1dc57e/attachment.html>