[openstack-dev] [neutron]load service provider dynamically

Germy Lure germy.lure at gmail.com
Tue Oct 21 06:25:24 UTC 2014


Hi all,

Maybe my description is not clear enough.
As is known to everyone, service provider provides ability for plugins to
schedule a different vendor. It is just a factor of scheduling. We should
integrate this into a United Schedule Module(USM) which provides scheduling
service for every plugins. This scheduling service can be based on
capability, resource, vendor, user-specific requirement and so on.
So how to get those information from back-ends? Statically configuring or
dynamically reporting? And those info are changing should be taken into
consideration. It's important to note that we have reported something in
current agent report implementation.
My suggestion is that agents (and controllers in phase 2) report their
capability, vendor, and other info to the USM in core. Every plugin invokes
the USM to schedule not dose it by their selves. We can even wrap
scheduling into agent-calling method(aka service driver), plugins can be
standardized and do not care vendors, agent or controller and other things.

BR,
Germy


On Mon, Oct 20, 2014 at 2:59 PM, Germy Lure <germy.lure at gmail.com> wrote:

> Hi Mathieu,
>
> Thanks for your response.
> I'm so sorry to reply you util today.(I was on a vacation)
> I have some comments inline.
>
> BR,
> Germy
>
> On Wed, Oct 8, 2014 at 7:34 PM, Mathieu Rohon <mathieu.rohon at gmail.com>
> wrote:
>
>> Hi germy,
>>
>> thanks for this interesting proposal.
>> To go further, It would be interesting to insert in your framework the
>> capacity to load service plugin dynamically, not only service providers.
>>
> Thanks for your suggestion. I think this has been included in the
> evolution part.
>
>> It as been discussed here [1][2]f or GBP needs, but it's something
>> interesting for other service plugin which want to be hosted in a
>> independent (stackforge) project.
>>
> It is different. My proposal targets agent and controller not plugin.
>
>> There is a line in the etherpad for kilo design summit about that [3]. I
>> hope this will be discussed.
>>
> Yes, I also hope.
>
>>
>> [1]https://review.openstack.org/#/c/116996/
>> [2]https://review.openstack.org/#/c/123620/
>> [3]https://etherpad.openstack.org/p/kilo-neutron-summit-topics
>>
>> Mathieu
>>
>> On Tue, Oct 7, 2014 at 3:51 PM, Germy Lure <germy.lure at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I have an idea about service provider framework. Anyone interested in
>>> this topic can give me some suggestions.
>>>
>>> My idea is that providers report their services capability dynamically
>>> not configured in neutron.conf. See details by the link below.
>>>
>>> https://docs.google.com/presentation/d/1_uNF0JEDyoFor8xj-MaaacPL334hiWJWB7NzfRrcVJg/edit?usp=sharing
>>>
>>> Everyone can comment this doc.
>>>
>>> Here are the main pages.
>>>
>>>
>>>
>>>>>>
>>>
>>>
>>>>>>
>>>
>>>
>>> ​BR,
>>> Germy
>>>
>>> _______________________________________________
>>> 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/20141021/10ee0d9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.png
Type: image/png
Size: 52202 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/10ee0d9a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.png
Type: image/png
Size: 35588 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/10ee0d9a/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 43224 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/10ee0d9a/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 37611 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/10ee0d9a/attachment-0007.png>


More information about the OpenStack-dev mailing list