Open Stack

Hi Youcef,

Please see my comments inline:

On Thu, Dec 6, 2012 at 11:58 PM, Youcef Laribi
<Youcef.Laribi at eu.citrix.com>wrote:

> Hi Eugene,****
>
> ** **
>
>   1) We may think of scheduler as a just a part of device management
> plugin since it is nothing more than an algorithm working on device list.*
> ***
>
> ** **
>
> This is why I want the confusion to be clarified. In your proposal, you
> had a scheduler per “service type”. This implies that the scheduler is not
> for LBaaS specific, it is common to all Service Plugins, so it cannot live
> in the LBaaS plugin.
>
The most basic requirement for the whole scheduling component is
configurability.
If we could write some scheduling algorithm in service type-agnostic way,
then we may configure it to schedule resources of several service types.
But such algorithm still has to be specified for each service type.
Example1:
[LBaaS]
scheduler=quantum.plugins.common.scheduler.ChanceScheduler
[..aaS]
scheduler=quantum.plugins.common.scheduler.ChanceScheduler
Example2:
Example1:
[LBaaS]
scheduler=quantum.plugins.lbaas.scheduler.LBspecificScheduler
[..aaS]
scheduler=quantum.plugins.common.scheduler.ChanceScheduler

So for simplicity we can just think that we will have LBaaS-specific
scheduling algorithms.

****
>
> ** **
>
> I also don’t want us to confuse the scheduler with device management. They
> may share the same database, but they have different functions in the
> system.
>
You're right. So lets define scheduler framework to be the following:
1) Infrastructure allowing to configure scheduling algorithm for service
type
2) Scheduling algorithms and their Adv Svc Plugins-facing interface
3) Code that interacts with device management plugin to retrieve device
list and make association of form (device, resource)

****
>
> ** **
>
> 2) We probably doesn't need separate "device agent" component and process.
> Any kind of device-specific task may be handled by common "advanced service
> agent" which routes messages from Adv Svc Plugins and Device Management
> Plugin to corresponding device-specific code.****
>
> ** **
>
> That is the type of reaction I was expecting by drawing the diagram J I
> agree with you that all device-specific code should be in the driver, but
> I’m not sure about having an “advanced service agent” routing to LBaaS
> plugin then to the LBaaS agent. But these are minor details we can discuss
> later.****
>
> ** **
>
> So, let’s first start clarifying the “service type” role. I think there is
> a lot of confusion here. Can we start sketching an API and payloads for
> creating them?
>
Actually, before doing that I'd like to see Salvatore's "service types and
service definitions" work. We need to see how it sticks together with what
we're discussing.

By the way, I thought that Salvatore was responsible for driving “service
> type” management, so I want to hear from him more on this, or whoever is
> now driving this piece.
>
That's right, although I think the scope of Salvatore's work is more close
to some service-level configuration API and infrastructure as well as
service insertion modes and doesn't include neither device management nor
scheduling.

****
>
> ** **
>
> Thanks****
>
> Youcef****
>
> **
>
Thanks,
Eugene.


> ** **
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Thursday, December 6, 2012 11:05 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Openstack-dev][Quantum][LBaaS] Quantum
> components needed for the LBaaS service****
>
> ** **
>
> Youcef,****
>
> ** **
>
> Thanks for the diagram, it quite close to what we are proposing.****
>
> A couple of additional notes:****
>
> 1) We may think of scheduler as a just a part of device management plugin
> since it is nothing more than an algorithm working on device list.****
>
> 2) We probably doesn't need separate "device agent" component and process.
> Any kind of device-specific task may be handled by common "advanced service
> agent" which routes messages from Adv Svc Plugins and Device Management
> Plugin to corresponding device-specific code.****
>
> ** **
>
> You may also look at workflow of pool creation operation as well as
> component diagram:  ****
>
> http://wiki.openstack.org/Quantum/LBaaS/Architecture/Scheduler****
>
> ** **
>
> ** **
>
> Thanks,****
>
> Eugene.****
>
> ** **
>
> On Thu, Dec 6, 2012 at 8:25 PM, John Gruber <john.t.gruber at gmail.com>
> wrote:****
>
> 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>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ** **
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ** **
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20121207/2ce991bb/attachment.html>